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ABSTRACT 



^ electronic Personal Information Manager (PIM) inclu d- 
ing a peer-to-peer gr oup scheduHng/cajendar jsystem '^is 
described. Tlie group scheduling/calendar system provi des 
methods for peer-to-peer group scheduling j gfflg_gggrs, 
i nctuding those users who only have simple fi^g ^jjlggPPort 
( i.e., do not have access to the group scheduling/ca^n ^ar 
system itself). I f a user is able to receive and respond t o 
e-mail, he or she is able to participate in group scheduli ng 
i n an automated fashion. U nder user control, the s^ tero 
generates a scnedulmg invitation incorporating ^ferent 
f ormats. Each format includes, in order of increasing conte nt 
richness, a simple text embedded scheduling invita tion, an 
HTML (Hypertext Markup Langgagcj~fojm^ einbedded 

scheduling invitation, and a proprietar^TbinaiyJ^M^^* 
(MnJupurpose inicmei Mail Extensions) s^eduling jnvita- 
l ioj^ jiacn formal Is aesigneg to transfer the highest degree 
ofrnformation content which a particular target client type 
can handle. A recipient of th e sched uling message em ploys 
the messaging tormat best s uiiea lor nis or her environment. 
Regacoiess ol whiCh lOtWal the recipient employs, the group 
scheduling system processes the reply message 
automatically, with the appropriate information automati- 
cally included in the user's group scheduling calendar. The 
system supports different levels of participation of various 
individuals throughout various stages of group scheduling, 
despite the fact that some of the individuals who need to 
participate might use other proprietary software and reside 
in other time zones. 
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other users in an automated fashion, but without requiring 
the users of the group to employ or be connected to a 
particular proprietary system. In particular, such a system 
should allow a user to initiate a message to invite a group of 
people to a meeting (i.e., to schedule a meeting). Those 
individuals should, if they are able to receive electronic 
mail, be able to participate in the group scheduling. Here, the 
recipients need not have access to any particular proprietary 
software for participating in the group scheduling. Instead, 
each participant need only be able to receive and send e-mail 
(which can be done using a wide variety of products, from 
numerous vendors.) The present invention fulfills this and 
other needs. 

SUMMARY OF THE INVENTION 

The present invention recognizes a user needs flexibility 
in choosing how appointments, events, and other time-based 
data are entered and managed, despite the fact that other 
individuals who need to participate might use other propri- 
etary software and reside in other time zones. According to 
the present invention, therefore, an electronic group 
scheduling/calendar system is provided with methods for 
peer-to-peer group scheduling among users, including those 
users who only have simple e-mail support (i.e., do not have 
access to the group scheduling/calendar system itself), or 
even have no c-mail support. 

According to the present invention, if a user is able to 
receive and respond to e-mail, he or she should be able to 
participate in group scheduling in an automated fashion. In 
"group scheduling^' — that is, notifying a group of people 30 particular, the present invention allows a user to undertake 
that a certain event is going to happen and receiving con- group scheduling with other "remote" users located at 
firmation from members of the group whether each can different locations (including those with different time 
participate. Conventionally, "group scheduling" has been zones), regardless of what particular platform or software 
largely limited to scheduling events for users within a applications each of the other users is employing. In contrast 
particular "work group." Typically, a "work group" has 35 to prior art scheduling approaches which required all users 
comprised those users connected together through a local to operate the same proprietary scheduling software, the 
area network (LAN). Alternatively, a "work group" can be present invention instead requires only one user of a work- 
extended to users who can receive messages. In this group to have the group scheduling software which the 
extended group, however, manual processing on the part of present invention is embodied. Every other user need only 
the user is typically required. For instance, for a user who 40 be able to send and receive e-mail messages — ^using any one 



SCHEDULING SYSTEM WITH METHODS 
FOR PEER-TO-PEER SCHEDULING OF 
REMOTE USERS 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent dociunent 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

BACKGROUND OF THE INVENTION 

The present invention relates generally to the area of 
information processing and, more particularly, apparatus 
and methods for managing and scheduling time-based infor- 
mation for multiple individuals located at different locations. 

Successful management of one's time is a goal that every 
successful professional must achieve. One's business day 
may be swept away in a deluge of meetings and 
appointments, all of which must be somehow managed. An 
attempt to manage this task on paper, such as with a simple 
wall calendar, is unworkable for all but the simplest of 
schedules. More likely, such unsophisticated aids to man- ^5 
aging one's time will lead to scheduling conflicts, missed 
appointments, botched deadlines, and angry clients. 

Oftentimes, it is necessary to schedule a group of people 
for an event, such as a meeting. This is the problem of 



20 



of the wide variety of e-mail packages which arc avaUable- 
in order to be automatically tracked by the system. Still 
further, the present invention includes facilities for accom- 
modating even those users who cannot receive e-mail. 

"E-mail" itself is a messaging-based approach which is 
exploited by the present invention for communicating with 
aU users, regardless of which proprietary system a given user 
is employing. The present invention implements a mess ag- 
ing subsystem or exchange which provide scheduling primi- 



connects from a remote location, the user is required to 
manually process messages received to manually update the 
calendaring product to update one's scheduling status infor- 
mation. This leads to two disjointed activities for the user: 
(1) retrieving messages and (2) entering/processing sched- 45 
uling information. 

With the ever increasing importance of the Internet, work 
groups are no longer confined to local area networks, or even 

wide area networks (WANs). Instead, people are connected 

together via electronic mail or "e-mail." At the same time, 50 t iyes (e.g.. "accept" and "decline" message types)]j ojLgup- 
however, users have become accustomed to the ease which porting the basic functionality of group sch eduling, even f or 
automatic scheduling systems provide, such as those which generic e-mail clients — th at is, a client which does not sha re 
operate within a proprietary environment (e.g., Novell nor is even aware of the group scheduling _so£tware sub- 
Groupwise® operating on a Netware® local area network). sy stem provided by the local client of the system of the 
If users are not connected to the same proprietary system S5 pr esent invention. T his include "dumb" remote cli ents 
(e.g. > Novell Groupwisc), then the users must resort to a which simply have no knowledge or understa nding, of the 
manual scheduling process. Here, the job typically falls to a sctieduiing torm at supported by the group schedulin g local 
secretary or administrative assistant who must contact each client " ~ 

proposed participant individuaUy, for determining his or her ~in tj^ical operation, for instance, group scheduling begins 
availability. Typically, the person charges with scheduling 60 with a user scheduling an event, that is, sending to desired 



the event must "negotiate" with the proposed participants for 
reaching a time when the meeting can finally happen. The 
process is still not complete, however. A confirmation mes- 
sage must be sent to all proposed participants for confirming 
the final time. 

What is really needed are system and methods which 
permit any user to schedule appointments with a group of 



participants an initial meeting message or "invitation" for 
scheduling the event. The event itself can be any type of 
event, including those with a duration (e.g., meetings and 
appointments); "resources" (e.g., conference rooms, 
65 projectors, and the like) can also be scheduled. The recipient 
uscr(s) can receive the message across a variety of different 
software platforms or e-mail solutions. 
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The message itself comprises an identifier, such as <ISK> cess the reply message automatically, includiag entering the 

(or other unique), together with a scheduling invitation in appropriate information in the user's group scheduling cal- 
different formats. The different formats include, in order of endar. In this manner, the system of the present invention 

increasing content richness, a simple text embedded sched- can support different levels of participation of various users 

uling invitation, an HTML (Hypertext Markup Language) 5 (none of which is required to have the system), throughout 

form embedded scheduling invitation, and a proprietary various stages of group scheduling, 
binary "MIME" (Multipurpose Internet Mail Extensions) 

scheduling invitation. Each format is designed to transfer the BRIEF DESCRIPTION OF THE DRAWINGS 
highest degree of information content which a particular 

target client type can handle. A remote client having the FIG. 1 A is a block diagram of a computer system in which 

scheduUng system of the present invention can recognizes Present mvenUon may be embodied, 

from the identifier that the message is firom another propri- FIG. IB is a block diagram of a software system of the 

etary client. Accordingly, the client can process the binary present invention for controlling the operation of the system 

"MIME" scheduling invitation natively. This message is a of FIG. L\. 

vendor-specific message, allowing direct, proprietary com- FIG. 2 is a bitmap scree nshot illustrating a user interface 

munication between proprietary clients with the richest of a Personal Information Manager which embodies the 

possible information content. present invention. 

Since other clients have no knowledge of the scheduling p[GS. 3A-C illustrate interclient communication which 

system, they simply ignore the identifier and the binary employs a message incorporating multi-format information 

attachment. To allow the local client to communicate with 20 embedded within. 

these recipient, non-proprietary interclient communicaUon ^ ^ ^> screenshol illustrating a "Deskpad" 

formats are employed. For instance a remote client with .^^^^^^^ -^^^ ^ ^ 

browser capability can employ the HTML form embedded ^ ..^ 1 . n . o l j 

scheduling invitation, which can be appropriately processed . 5A-I are bitmap screenshote lUustrating a Sched- 

by its Web browser (e.g., Microsoft Explorer or Netscape 25 "^^^ ^'"''^ ""''"^"^^ ^'^""^^ ^^^^"^ 

Navigator); this represents the richest content that this client events. 

type can handle. The embedded HTML form (i.e., Web FIGS. 6A-C are bitmap screenshots illustrating a pre- 

page) can easily be viewed by the Web browser as an input ferred interface provided by the system for processing 

form having input fields corresponding to the information incoming event invitations. 

requested for scheduling the event. For instance, the form 30 FIGS. 7A-C are bitmap screenshots illustrating a pre- 

may include text or input fields for subject, time, event, and ferred interface provided by the system for processing 

the like. Additionally, the form can include screen buttons incoming replies. 

for allowing the recipient user to "accept" or "decline'' the FIGS. 8A-G are bitmap screenshots illustrating a pre- 

invitation. At the conclusion of completing the input form, ferred interface provided by the system for scheduling use of 

the recipient user can select "submit" for returning the input 35 resources. 

information back to the initiator. Here, the browser of the g ^ ^j^^ ^•^^^^^ providing an overview of the 

recipient generates a reply message, m a manner simUar to -^^^^^^^ architecture of a group scheduling system of the 

that done today for on-line Internet registration. Upon present invention 

receipt of the reply, the originating client can identify, •„ * , 

decode, and process the reply appropriately. 40 ^0 is a block diagram lUustratmg the general process 

T *u * *t. . *u • • * V * • • 1 .. of sending an event. 

In the event that the recipient client is a simple e-mail ^ 

client, the recipient client employs the simple messaging F^G. 11 is a block diagram iUustrating the general process 

format incorporated into the scheduling message. Here, the receiving messages. 

recipient client can view a plain text e-mail message to FIGS. 12A-C are bitmap screenshots illustrating receipt 

which the user can respond (e.g., "accept" or "decline"). In 45 ot an e-mail scheduling invitation by a recipient whose 

the recipient cUent's reply, the client includes the "body" of system represents a non-SK client without browser support, 

the initial invitation message. As is common in e-mail FIG. 13 is a screenshot illustrating receipt of an e-mail 

communication, the reply message can itself easily incor- scheduling invitation by a recipient whose system represents 

porate the contents of the original message. By simply a non-SK client with browser support, 

including the initiator's original message when a non-SK 50 

client replies, the non-SK chtnt is incorporating information DETAILED DESCRIPTION OF A PREFERRED 

which facilitates processing of the reply by the SK local EMBODIMENT 

client For instance, the reply includes the "ISK" signature The following description will focus on the presently 

which is embedded within the subject line. Other informa- preferred embodiment of the present invention, which is 

tion includes the e-mail address of the recipient as wcU as 55 operative in an end-user application running under the 

the recipient's response (e.g., "accept") using delimited key Microsoft® Windows environment. The present invention, 

words. Upon receiving the reply, the initiator can recognize however, is not limited to any particular one application or 

that the response (e.g., an "accept" message or a "decline" any particular environment. Instead, those skilled in the art 

message) corresponds to a particular invitation send out, will find that the system and methods of the present inven- 

thus facilitating decoding and processing of the message. In eo tion may be advantageously applied to a variety of system 

this manner, the response includes sufi&dent scheduling and application software, including database management 

information embedded within it to allow the initiator cUcnt systems, wordprocessors, spreadsheets, and the like, 

to appropriately decode the response, despite the fact that the Moreover, the present invention may be embodied on a 

responding recipient ^is a simple e-mail client without variety of different platforms, including Macintosh, UNIX, 

browser capability. 65 NextStep, and the like. Therefore, the description of the 

Regardless of which format the recipient employs, the exemplary embodiments which follows is for purposes of 

group scheduling system of the present invention can pro- illustration and not limitation. 
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System Hardware 

The invention may be embodied on a computer system 
such as the system 100 FIG. lA, which comprises a central 
processor 101, a main memory 102, an input/output con- 
troller 103, a keyboard 104, a pointing device 105 (e.g., 5 
mouse, trackball, pen device, or the like), a display or screen 
device 106, and a mass storage 107 (e.g., hard or fixed disk, 
removable floppy disk, optical disk, magneto -optical disk, or 
flash memory). Although not shown separately, a real- time 
system clock is included with the system 100, in a conven- 
tional manner. Processor 101 includes or is coupled to a 
cache memory 109 for storing frequently accessed informa- 
tion; memory 109 may be an on-chip cache or external cache 
(as shown). One or more input/output device(s) 108, such as 
a printing device or slide output device, arc included in the 
system 100, as desired. As shown, the various components 
of the system 100 communicate through a system bus 110 or 
similar architecture. In a preferred embodiment, the system 
100 includes an IBM PC-compatible personal computer, 
available from a variety of vendors (including IBM of 
Armonk, N.Y.). I/O device 108 may include a laser printer, 20 
such as an HP Laserjet printer, which is available from 
Hewlett-Packard of Palo Alto, Calif. 
System Software 

A. Overview 

Illustrated in FIG. IB, a computer software system 120 is 25 
provided for directing the operation of the computer system 
100. Software system 120, which is stored in system 
memory 102 and on storage (e.g., disk memory) 107, 
includes a kernel or operating system (OS) 140 and a 
windows shell 150. One or more application programs, such 30 
as cUent application software or "programs" 145 may be 
"loaded" (i.e., transferred from storage 107 into memory 
102) for execution by the system 100. 

System 120 includes a user interface (UI) 160, preferably 
a Graphical User Interface (GUI), for receiving user com- 35 
mands and data. These inputs, in turn, may be acted upon by 
the system 100 in accordance with instniclions from oper- 
ating module 140, windows 150, and/or client application 
module(s) 145. The UI 160 also serves to display the results 
of operation from the OS 140, windows 150, and application 40 
(s) 145, whereupon the user may supply additional inputs or 
terminate the session. OS 140 and windows 145 can be 
provided by Microsoft® Windows 95, by Microsoft® Win- 
dows NT, or by Microsoft® Windows 3.x (operating in 
conjunction with MS-DOS); these are available from 45 
Microsoft Corporation of Redmond, Wash. Although shown 
conceptually as a separate module, the UI is typically 
provided by interaction of the application modules with the 
windows shell, both operating under OS 140. 

One apphcation software comprises a Personal Informa- 50 
tion Management (PIM) System 125 which includes an 
Internet-based Group Scheduling Module 127 of the present 
invention. The Internet-based Group Scheduling Module 
127 provides group scheduling among users connected to 
the Internet or to other commercial service providers (e.g., 55 
CompuServe), In an exemplary embodiment, PIM System 
125 comprises Sidekick®, which is available from Starfish 
Software, Inc. of Scotts Valley, Calif. A general description 
of the operation of Sidekick® can be found in its accom- 
panying user manual. Interface and methods provided by the 60 
group scheduling module of the present invention, in the 
exemplary embodiment of Sidekick®, will now be 
described in further detail. 
Peer-to-Peer Scheduling 

A. General 65 

According to the present invention, if a user is able to 
receive and respond to e-mail, he or she should be able to 
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participate in group scheduling. In particular, the present 
invention allows a user to undertake group scheduling with 
other "remote" users located at different locations (including 
those with different time zones), regardless of what particu- 
lar platform or software applications each of the other users 
is employing. In contrast to prior art scheduling approaches 
which required all users to operate the same proprietary 
scheduling software, the present invention instead requires 
only one user of a workgroup to have the group scheduHng 
software which the present invention is embodied. Every 
other user need only be able to send and receive e-mail 
messages — ^using any one of the wide variety of e-mail 
packages which are available. Still further, the present 
invention includes facilities for accommodating even those 
users who cannot receive e-mail. 

"E-mail" itself is a messaging-based approach which is 
employed by the present invention for communicating with 
all users. The present invention implements a messaging 
subsystem or exchange which provide scheduling 
primitives — for example, "accept" and "decline" message 
types — for supporting the basic functionality of group 
scheduling. In typical operation, for instance, group sched- 
uling begins with a user scheduling an event, that is, sending 
to desired participants an initial meeting message or "invi- 
tation" for scheduling the event. The event itself can be an y 
t ype of event, including thosc^witha duratio n (e.g., mee tings 
and pp pn^'T itpienLs^! as described below, "resources (e .g., 
conference rooms, pro j ectors, and the like) are also^.a ched- 
uled. The recipient user(^s), once having received the 
message, can undertake one of several actions. T he user ca n 
a ccepl^pr decline^tcyparticipate. or the user can forwar 'd the 
message to one_or more__other._u sers.. When dechoing a 
proposed scheduling event, the user can propose another 
time for the event. When a user declines, he or she replies 
with a "decline" message; the message may include one or 
more alternative times proposed by the declining user . The 
decline message is processed up on its return, whereupori'j he 
^yst^rtj a 'liConTaticali y updates T he sche duling calenda r. An 
icccpnhg user, on ttie ^Iher hand, replies'with an "accept" 
message. Again, the group scheduling system processes the 
^message automaticaUy , in cluding enterin g t he appropriat e 
m iortb'aiion m ttie"^roup^che aui mg""calendar. Jn this 
manner^ the system^oi' the present invention can support 
different levels of participation of various users (none of 
which is required to have the system), throughout various 
stages of group scheduling. 

B. Functional Overview 

FIG. 2 is a block diagram illustrating a functional over- 
view of a group scheduhng system 200 of the present 
invention, from the perspective of an end user. The system 
includes a local client 210 comprising front-end software, 
including a graphical user interface, for entering scheduling 
information and generating group scheduling messages. The 
client 210 connects to transport mechanism or messaging 
engine 220. This provides the mechanism whereby the client 
210 can send messages to and receive messages from remote 
clients. 

In a preferred embodiment, the messaging engine 220 
supports Microsoft is Exchange or MAPI (Messaging Apph- 
cation Programming Interface), AOL (America On Line), 
and POP 3 (Internet "Post Office Protocol)" messaging 
protocols. These widely-supported protocols can be 
employed for reaching remote cUents having addresses (i.e., 
accounts) on the Internet, America On Une, Microsoft 
Network (MSN), as well as other systems which are acces- 
sible through gateways (e.g., Compuserve, which has an 
Internet gateway). To further support each messaging or 
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mail system, the client 210 includes an address book module 
230, which comprises a separate address book for each 
messaging system. In an exemplary embodiment, for 
instance, the system provides support for AOL address book, 
Internet (Netscape) address book, and MAPI-exchange 
address book. 

With the messaging engine connection, the client 210 is a 
"local" client which exchanges messages with various 
"remote" clients, such as client 240, client 250, and client 
260. As shown, there are different types of remote chcnts. 
One type of remote client is one which shares the same 
software group scheduling subsystem as the local client 210 
(i.e., it "understands" proprietary file formats of the local 
client 210). Such a client is shown at 240. Here, the local 
client 210 and the remote client 240 can of course commu- 
nicate directly using the proprietary format understood by 
both, in the same manner as presently done by present-day 
proprietary group scheduling solutions. 

According to the present invention, however, a remote 
client may also comprise a generic e-mail client — that is, a 
client which does not share nor is even aware of the group 
schcduHng software subsystem provided by the local client 
of the present invention. These "dumb" remote clients, such 
as represented by clients 250 and 260, simply have no 
knowledge or understanding of the scheduling format sup- 
ported by the local client 210. For clarity of the description 
which follows, the generic or non-proprietary clients are 
referred to as "non-SK" clients, for indicating that these 
clients do not have Sidekick® — the proprietary software 
which implements automated group scheduling with both 
proprietary and non-proprietary clients. Those clients which 
do have Sidekick® are referred to a "SK" clients. 

With the ever-increasing use of the Internet and particular 
the rapid adoption of the World-wide Web ("Web") as a 
pervasive communication platform, an ever-increasing num- 
ber of non-proprietary remote clients wiU have a standard 
browser, such as Netscape Navigator (available from 
Netscape of Mountain View, Cahf.) or Microsoft Internet 
Explorer (available from Microsoft Corp. of Redmond, 
Wash.). As described in further detail below, the present 
invention may exploit this by using rich text messages, such 
as e-mail including one or more HTML (Hyper Text Markup 
Language) forms or *'Web pages/' Such a client, such as 
shown at 250 in FIG. 2, is identified as a remote non-SK 
client "with browser." A simple e-mail client, on the other 
hand, is identified as a remote non-SK client "without 
browser." 

C. Interclient Communication 

The local SK client communicates with other clients by 
employing its messaging engine or transport layer to sends 
and receives electronic mail or messages. As illustrated in 
FIGS. 3A-C, each message itself is structured to facihlate an 
optimal communication protocol appropriate for the differ- 
ent types of clients (i.e., SK client, non-SK client with 
browser, or non-SK client without browser). This is 
achieved by incorporating into the message different formats 
of the scheduling message — one format for each particular 
client type. 

To allow rapid identification of scheduling messages 
between SK clients themselves, an identifier or "signature" 
is incorporated into the message by tagging the standard 
"subject line" in each e-mail message. In an exemplary 
embodiment, the initiator of a message (i.e., local SK client) 
includes the following unique identifier in the subject line of 
<1SK> or, alternatively, <SIS>. The interpretation of this 
depends on the actual type of client the recipient is. Remote 
recipient clients which do support the proprietary format of 
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the local cUent (i.e., recipient SK remote clients) can rec- 
ognize the identifier and readily identify the message as a 
scheduling message from another SK client. This allows all 
SK clients to easily identify scheduling messages among 

5 themselves, thus facilitating decoding and processing of 
messages. In the instance of one SK client communicating 
with another SK client, therefore, the recipient is a "smart" 
client with full knowledge and understanding of the type of 
message and how to interpret it. 

10 One such SK-client-to-SK-client dialog is illustrated by 
interclient communication 300 in FIG. 3A. Local SK client 
sends e-mail message 310. The message comprises the 
<ISK> (or other unique) identifier 311 together with a 
scheduling invitation in different formats. The different 

15 formats include, in order of increasing content richness, a 
simple text embedded scheduhng invitation 313, an HTML 
(Hypertext Markup Language) form embedded scheduling 
invitation 315, and a proprietary binary "MIME" 
(Multipurpose Internet Mail Extensions) scheduling invita- 

20 tion 317. 

Each format is designed to transfer the highest degree of 
information content which a particular target client type can 
handle. In FIG. 3A, for instance, remote client 320 recog- 
nizes from the identifier 311 that the message 310 is from 

25 another SK client — SK local client 301. Accordingly, the 
remote SK client 320 processes the binary "MIME" sched- 
uling invitation 317.This message is a SK-specific message, 
allowing direct, proprietary communication between SK 
clients with the richest possible information content. 

30 Description of the MIME format is well documented in the 
trade literature; see e.g., Kientzle, T, MIME and Internet 
Mail, Dr. Dobb's Journal, September 1995, pp. 54-60 (with 
code listings pp. 104-110), the disclosure of which is hereby 
incorporated by reference. 

35 Since non-SK clients have no knowledge of the schedul- 
ing system, they simply ignore the identifier and the SK 
binary attachment. To allow the SK local client to commu- 
nicate with these non-SK recipient, the non-proprietary 
interclient communication formats 313, 315 are employed. 

40 As shown in FIG. 3B, for instance, remote non-SK client 
with browser 340 employs the HTML form embedded 
scheduling invitation 315, which can be appropriately pro- 
cessed by its Web browser (e.g., Microsoft Explorer or 
Netscape Navigator); this represents the richest content that 

45 this client type can handle. 

The embedded HTML form (i.e., Web page) can easily be 
viewed by the Web browser as an input form having input 
fields corresponding to the information requested for sched- 
uling the event. For instance, the form may include text or 

50 input fields for subject, time, event, and the like. 
Additionally, the form can include screen buttons for allow- 
ing the recipient user to "accept" or "decline" the invitation. 
At the conclusion of completing the input form, the recipient 
user can select "submit" for returning the input information 

55 back to the initiator. Here, the browser of the recipient 
generates a reply message, in a manner similar to that done 
today for on-line Internet registration. Upon receipt of the 
reply, the SK client 210 can identify, decode, and process the 
reply appropriately. Based on the action selected by the 

60 recipient (e.g., accept, decline, or the like), the SK client 210 
can update its scheduhng information in an appropriate 
manner. 

In the event that the client is a non^K client and does not 
have a browser, a simple messaging format is employed. As 
65 shown in FIG. 3C, remote non-SK client without browser 
360 processes the simple text embedded scheduling invita- 
tion 313, as this represents the richest content that it can 
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handle. Here, the recipient client receives a plain text e-mail 
message to which it can respond (e.g., "accept" or 
"decline"). In the client's response, the client includes the 
"body" of the initial invitation message. As is common in 
e-mail communication, the reply message can itself easily 
incorporate the contents of the original message. By simply 
including the initiator's original message when a noQ-SK 
client replies, the non-SK client is incorporating information 
which facilitates processing of the reply by the SK local 
client. For instance, the reply includes the "ISK" signature 
which is embedded within the subject line. Other informa- 
tion includes the e-mail address of the recipient as well as 
the recipient's response (e.g., "accept") using delimited key 
words. Upon receiving the reply, the initiator can recognize 
that the response (e.g., an "accept" message or a "decline" 
message) corresponds to a particular invitation send out, 
thus facilitating decoding and processing of the message. In 
this manner, the response includes sufficient scheduling 
information embedded within it to allow the initiator client 
to appropriately decode the response, despite the fact that the 
responding recipient is a non-SK client without a 
browser — a simple, generic e-mail cUent. 
D. Resource Scheduling 

When a meeting or an event is scheduled, often 
"resources" will be needed as well. For a board meeting, for 
instance, the board room needs to be available. The meeting 
might also require other resources, such as an overhead 
projector or a VCR. In accordance with the present 
invention, the scheduling system is extended to include 
these "resources." As with users, the resource scheduling is 
peer-to-peer — that is, it is shared among the users in a 
cooperative fashion. 

A resource itself "owns" an e-mail account — that is, it is 
able to send and receive scheduling messages. In this 
manner, scheduling of the resource can be completely auto- 
mated. Here, the resource is controlled by an SK client, 
which manages the calendar for the resource. When a 
request is received to schedule the resource, the SK client 
can check its calendar and respond whether the resource is 
available, all in an automated fashion. For the example of a 
board room meeting, the board room resource is, in effect, 
"invited" to the meeting. Through the SK client which is 
controlling the scheduling calendar for the board room, the 
board room can "reply." In a preferred embodiment, an 
immovable resource (e.g., "room" resource) cannot be 
scheduled to attend two meetings at the same time. A person, 
on the other hand, can be scheduled for two meetings at the 
same time; in that instance, the person decides which 
meeting to attend (i.e., which one is more important), or 
decides to attend certain portions of each meeting. 
Preferred Interface and User Operation 

A. General Interface 

As shown in FIG. 4, the system provides a "Deskpad" 
interface 400 — that is, a personal information management 
interface which includes an electronic appointment calendar. 
The interface 400 includes a menu bar 410, for invoking 
menu items or commands. The interface itself is comprised 
of particular subregions. A first subregion 420 displays the 
current time and date. Below this region are a To Do region 
430 and a Call region 440. The former lists To Do items 
which the user has included. The latter is a log of calls which 
the user wishes to track. Actual schedule events or appoint- 
ments are displayed in the interface at region 450. By 
default, appointments are displayed in one's own local time. 
The interface also includes a quick lookup or viewport 460, 
for working with another view of the interface (e.g., "Card- 
file" view). Finally, the interface includes Deskpad icons 
470, for quickly switching to other modules of the system. 



The interface 400 provides different "views": Calendar 
view, Cardfile view. Write view. Expense view, and Activi- 
ties view. The Cardfile view can be used as an address book 
in which the user stores names, addresses, e-mail addresses, 

5 phone numbers, and other information (e.g., record 
collection). The Cardfile works with the Calendar's Internet 
group scheduling to address event invitations, and also can 
look up phone numbers of incoming calls using Caller ID. 
The user can use the Cardfile with the Phone Dialer to dial 

10 calls, or merge card information into a letter using Quick 
Letter. The Write view provides a place to create and format 
documents, organized in folders and binders. The Expense 
view lets the user enter information from expense receipts, 
and organize expenses in folders. The user's expenses arc 

15 printed in a finished expense report. The Activities view 
presents information about all the user's group scheduling 
events plus other Calendar activities: one's calls. To Do 
items, and individual appointments for the period selected. 
The Activities view is employed to reply to group event 

20 invitations and view replies to group events the user has 
originated. 

Of particular interest to the present invention is the 
Calendar view which, as shown in FIG. 4, displays the user's 
Calendar. Here, the user creates appointments and uses 

25 Internet-based messaging (or other electronic messaging 
service) to automatically handle invitations and replies for 
scheduling group events. The appointments adjust to the 
user's own local time zone, if the user travels with the 
computer when he or she switches to the new local time in 

30 an "EarthTime" module of the system. The EarthTime 
module tells the user the current time in eight locations 
arotmd the globe, and provides other information such as 
time difference start and end of daylight saving time, and 
other facts about each city, for over 540 cities. Further 

35 description of the EarthTime module is provided in 
commonly-owned application Ser. No. 08/609,983, filed 
Feb. 29, 1996, which is hereby incorporated by reference. 
When desired, the user can print the Calendar in a variety 
formats, including page sizes suited to the most popular day 

40 planners, such as Keith Qark, DayRunner, Day-Timers, and 
Franklin Planner. 

B. Peer-to-Peer Scheduhng Interface 
1. Overview 

The Group Scheduling module 127 uses electronic mes- 

45 saging to communicate with others to schedule events and 
book resources. Because it supports numerous e-mail 
platforms, including the Internet, the module can provide 
group scheduling with users anywhere in the world. The 
system automatically invites the participants to an event the 

50 user schedules, and collects their rephes for accepting or 
declining the invitation or for requesting that the user 
reschedule it. The event is automatically placed in the 
Calendar in the Calendar view, as well as the recipients' 
calendars if they accept. Additionally, the user can also 

55 automatically reserve resources for the event, such as con- 
ference facilities, projectors, and others. Most of the group 
scheduling occurs in the Activities View, where the user can 
see all group events in list form. Events the user schedules, 
or that the user accepts an invitation to, are also posted 

60 automatically in the user's Calendar. 

To schedule an event, _the user enters the details of the 
meeSnp and the list oLp eonl e he or she w ants to invite. The 
system then automatically notifies the recipientg'and'oollec ts 
their responses for the user^ In addition to electronic . 

65 messaging, the user can use Tax or telephone for group 
scheduling, for people without e-mail accounts. If the user 
specifies a fax number for notification, the event invitation 
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is automatically sent using built-in fax software (e.g., 
Microsoft Fax) and the user's fax modem. Selecting phone 
notification, on the other hand, puts a reminder in the user's 
Calls list. 

2. Scheduling Wizard 5 

The system provides a convenient "Scheduling Wizard" 
to assist the user in the process of entering event informa- 
tion. It helps the user enter all the information about the 
event, and identify the participants he or she wants to invite. 
The user also can create a group event using a "Schedule an lO 
Event" dialog box. The user can include a message with the 
invitation, and the replies can include a message and a report 
on free time if a recipient cannot attend at the scheduled 
time. If the user needs to notify some people by fax or phone, 
he or she can enter their reply status manually. 15 

Thexa sicst way to enter group event information is us ing 
the Scheduling Wizard . To schedule an event in the Ac tivi- 
tie s or Calendar viewT the user selects Internet| Schedujing 
Wizard from the main menu, as shown at 5 005^10. j A 
Th is action launches Sch eduling Wizard SfO, as shovm in 20 
FI G75B. The wizard c onsols of a ser ies of p age s th at projn^t 
t he user to enTefTIfie inf ormation 1 ^ t he event, "sucQs 
paTticipants,'^ resources , agenda or notes, ah d^options4 The 
u ser enters the information in each page, and clicks "Nex t" 
to 'proceed to the next page.^T he u ser can go back at any tim e 25 
t o earlier pages it he or she needs to ch ang e^ some thing. 
When the user has finished, the j /system displays an Eve nt 
S ummary. Here, the user can review his or ber choices,^nd 
make changes, if necessary, by going back to previous 
pages, \ yhen the user is ready to schedule the event, the 30 
Wizard a dds it to the _us e r*s queu e of outgo i ng messages, and 
p ut it on thTuser's calendar/ Io'use Ynternet schedulmg," the 
user creates a cardfile that contains properly identified 
e-mail addresses for the people the user will be inviting. 
Alternatively, the user can use an existing Netscape Address 35 
Book or Microsoft Exchange Cardfile for addressing. 

The wizard is used from start to finish as follows. First, 
the user enters an event type. As illustrated in FIG. 5C, the 
user clicks an event category at 511 and selects a particular 
subject — that is, an event type to schedule. When the user 40 
has completed each Wizard panel, the user clicks "Next" 
button 512 to continue. Alternatively, the user can click 
"Back" to return to an earlier panel. Next, in FIG. 5D, the 
user invokes the "Date and Time" page. Here, the user 
reviews the subject presently entered, at 521, and then enters 45 
a dale and time for the event, at 522. The user can select the 
date by typing or by using the arrows. A calendar can be 
opened at this point (e.g., by selecting the large arrow). The 
user also enters the start and end times. Next, the user selects 
or types the city where the event is to occur, at 523. The dme 50 
zone fills in automatically. After typing or selecting a place, 
the user advances the wizard to the next pane by selecting 
Next button 524. 

The next pane is a "Participants" page, illustrated in FIG. 
5E, which allows the user to select participants. At 531, the 55 
user chooses an Address Book or a mailing list; clicking 
"More" opens a different Address book. Now, the user clicks 
the folder next to each name, and clicks the notification 
method (i.e., e-mail, fax, or the like) for that participant. The 
user adds desired selections to the Participants list 533 or CC 6o 
list 534, using selection buttons 535. Thereafter, the user 
moves to the next pane by selecting Next button 536. On the 
"Message" page, shown in FIG. 5F, the user types the 
agenda or notes, at 541. From buttons 542, the user can click 
a "Message" button to select a file containing a message. 65 
Alternatively, the user clicks "Attach URL" (Uniform 
Resource Locator, the address of a site on the World Wide 



Web) to add an Internet address as part of the message 
information. Users receiving the URL can click on it to 
launch their Web browser and jump to the URL site. At 543, 
the user can select a file to send as an attachment to the 
meeting invitation. The user proceeds to the next pane by 
selecting Next button 544. The next pane or page is the 
"Resources" page, illustrated in FIG. 5G, where the user 
selects one or more resources from a list 551 of available 
resources. The user clicks the selection buttons 553 to add or 
remove items from the Event Resources list 552. By clicking 
Next button 554, the user proceeds to the next page. 

The next page is the "Event options" page, illustrated in 
FIG. 5H. At 561, the user can select a check box to send a 
reminder as well as set an amount of advance notice. By 
checking "Page Me" or "Alert Me" and setting a time, the 
user can instruct the system to remind the user by page or 
alarm. The user selects the RSVP radio button, in Event 
Options box 562, to request a reply, or selects the FYI radio 
button to send an aimouncement only. By selecting RSVP 
(i.e., "please respond"), recipients can send back a reply 
whereupon the system automatically collects the informa- 
tion for the user. If the user chooses FYI (i.e., "For Your 
Information"), on the other hand, he or she is sending an 
announcement of the event, without requesting replies. This 
option is used, for example, for events such as a company 
meeting that will occur regardless of individual schedules. 
Additionally, in Event Options box 562, the user can instruct 
the system to enter this Event in the user's Contact Log. 
Upon checking the box, the event is entered in the Contact 
Log for each participant in the invitation List. Finally, the 
user can specify a type for the event: Public, Personal, or 
Confidential. 

Upon selecting Next button 563, the user instructs the 
system to proceed to the "Schedule the Event" page, illus- 
trated in FIG. 51. Here, the user can review the selections, at 
571, and go back to any previous page, if needed. Once 
satisfied with the selections, the user selects "Finish" button 
572 to schedule the event. Alternatively, the user can cancel 
the input altogether by selecting "Cancel." 

The user can also include people who do not have e-mail 
in the list of event invitees. Here, two options exist for 
addressing invitations: fax or telephone. If an invitation is 
directed to someone at their fax address, the system launches 
the fax software (e.g., Microsoft Fax) and faxes the invita- 
tion automatically. If the user selects someone's telephone 
number as their address, a reminder is added to the user's 
Calls list in the calendar to call that person. When the user 
hears from these people, he or she can enter their meeting 
reply by entering the appropriate status: Accept, Decline, 
Reschedule Request, or Delegate. 

3, Incoming Event Invitations 

When the user receives an invitation to an event, it 
appears in bold type in the Activities view 600, which is 
illustrated in FIG. 6A. An icon appears in the News column 
623 to indicate a new event. The user will see the incoming 
event invitation in his or her e-mail in-box, marked with the 
signature (e.g., <ISK> for Internet Sidekick) in the subject. 
In typical operation, the user disregards this message in his 
or her e-mail in-box, as the system will automatically find 
and handle it for the user. Users who have other systems, on 
the other hand, can open the message like any other e-mail; 
it contains instructions on how to reply so the original 
sender's system (i.e., SK client) will be able to record the 
reply. 

To gel to the Activities view, the user dick the Activities 
icon (or selects the corresponding menu command). After 
the user has chcked Group Events tab 611, status informa- 
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tioD is displayed for group events in the three left-hand 
columns. Type column 621 displays an icon for the event 
type: (b 1) New event the user initiated; (2) New incoming 
event, and (3) Incoming event the user has opened. News 
column 623 displays an icon for all new items: (1) New 5 
event information; (2) Reply has arrived; and (3) Event has 
been canceled. Out-box column 625 indicates messages that 
are queued to be sent during the user's next e-mail flash 
session; it displays an icon indicating Messaging waiting to 
be sent. The user can select an Internet |Send/Receive Now lO 
command to send pending messages immediately. By click- 
ing on a Detail item 627, the user can display further 
information in Details and Information pane 629. 

T o reply t o an eve nt invitation, the user reviews the eve nt 
sp eciiics in tbc uciaifean d I nformation pa nes. The n, the use r 15 
clicks a choice to T^y^from the buttons afthe bot ttom of the 
w indow (e.g., "Accept," "Dedinc/' "RescheSulc;" or t he 
Q ce). Alternatively, the user ca njjght-c lLck an eve nt in the 
top pane, and choose from a ShortcuTm cnu. I n a preferre d 
embodiment, thcuscr^s reply. is_sent onlylo tje ongjna tpr, 20 
n5t to others invited t^the event. 

"Ac cept button Mi icLS lhe 'Ti'xf.r enter n ^hngp^triv 

message (via Reply dialog 635 in FIG. 6B), and then send s 
the acccpt ance to the initiator conlirmingih aLthe. user will 
attena. m e event is automatically added to the jjs er's 25 
cale'naar. uecl me putton 633, on the other hand, se nds a 
rep ly message to the initiator that the user will not be able 
to attend. I he event is not added to the user's calendar. W ith 
t he user^s retilv, the user can mclude a Free l ime repo rt 
sho wmg the ii ser'^y oked and unboolcecl time for the n ext 
3 0 days (o r q lSej user-sp£cifieaintef^aJL^, tor assisting the 
meeting originator in rescheduling. |Included in the Free 
Time report is an indication of all the tunes for the next 30 
days when the user has a scheduled event, and all other (free) 
times. In a preferred embodiment, no information about 35 
specific events on the user's calendar is sent, beyond the 
indication that the time is booked. The user checks box 637 
to include the report. 

In addition to accepting or declining, the recipient user 
can request rescheduling of the event. Here, the user selects 40 
Reschedule Request button, such as button 635 in FIG. 6A. 
In response, the system displays Reschedule Request dialog 
640, as shown in FIG. 6C. This option sends a reply 
requesting that the event be moved to another time or date. 
In the dialog, the user can enter one or more alternate times 45 
for the event, as weU as include a short message. As with the 
decline response, the user has the option of including a Free 
Time report to assist the meeting originator in rescheduling. 
The Muiutes button 634 is tised to send notes or minutes to 
all participants. This launches a ''Compose the Minutes" 50 
window where the user can write a message or attach a file 
(by clicking a Browse button); the minutes are automatically 
distributed to the participants. 

Besides accepting and declining, the user can "delegate" 
the event by choosing the option from the menu. The option 55 
opens a Delegate To dialog box (not shown), where the user 
can specify a person to forward the invitation to. Here, the 
meeting originator is notified that the user has delegated the 
event to someone else. 

4. Replying to Incoming Event Invitations for Non-SK 60 
Clients 

Users who are non-SK client users (i.e., do not have 
Internet Sidekick installed) can still reply to incoming 
invitations in a way that is automatically recorded by the 
event originator's. All event invitations, whether the recipi- 65 
ent is a non-SK dicnt user or an SK client user, appear in the 
user's e-mail in-box. Users who are SK client users can 



ignore the messages, since the system will read and process 
these automatically. 

Non-SK client users can open the invitation like any other 
e-mail item and read the contents, which are stored in 
formatted text. The body of the message includes instruc- 
tions that explain briefly how a non-SK client user can reply. 
To reply to an invitation using conventional e-mail software, 
the non-SK client user proceeds as follows. The user opens 
the invitation in his or her e-mail in-box, like any other 
message. Using the user's own e-mail software (firom any 
vendor), the user "replies" to the message, and includes the 
body of the original message in the reply (i.e., does not 
modify the contents). The subject field of the reply will 
already include <ISK> indicating that the reply is an Internet 
Sidekick scheduling message. In the body of the message, 
the user finds a section labeled "Your Reply." Here, the user 
simply types an "X" in the brackets next to Accept or 
Decline, so that the reply reads "[X] Accept" or "[X] 
Decline"; the replying user can also type a brief message in 
the space between the markers reading < BEGIN REPLY 
MESSAGE> and <END REPLY MESSAGE>. Now the user 
simply sends the reply. The originator's SK client will be 
able to process the reply automatically and mark the appro- 
priate status for that recipient. 

5. Incoming Replies 

The originator's SK cfient automatically collects reply 
messages from people which were invited to an event and 
displays the replies in the Activities view. As replies arrive, 
the user is notified by an icon in the News column (623 in 
FIG. 6 A). The user can click the participants' names in the 
Activities view, and read their reply status, as well as any 
reply message they may have sent, in the Details and 
Information dialog 700, shown in FIG. 7A. By clicking the 
+ sign by the participants in Details pane 701, the user can 
expand the list. By clicking a participant, the user can view 
the reply message in Information pane 703 and expand the 
Details and Information panes to full-screen, as desired. 

The originator user can reschedule an event which he or 
she originated by selecting the event and clicking Resched- 
ule button 711. This action displays a "Schedule an Event" 
dialog box where the user enters the new dale and time 
information, and any other changes. The user is asked if he 
or she wants to notify all participants and resource managers 
about the change. If the user selects "Yes," notification is 
automatically sent. 

In a similar manner, the user can cancel an event he or she 
originated by selecting the event and clicking Cancel Event 
button 713. The user will be asked to confirm that he or she 
wants to cancel the event and notify all participants; select- 
ing "Yes" cancels the event. Alternatively, the user can 
delete group scheduling events in the Activities view to 
clean up his or her events list. This is done by selecting one 
or more events and pressing the Del key, or by right-clicking 
an event and choosing Delete from the menu. In contrast to 
canceling, the action of deleting group events in the Activi- 
ties view does not remove them from the user's calendar, 
and does not notify meeting participants. It is used only to 
clean up the Activities list display. To delete a group event 
the user has originated and notify participants, the user 
clicks the Cancel Event button 713 or deletes the event in his 
or Calendar. 

Also in the Details and Information dialog 700, the user 
can elect to send a reminder to all event participants in 
advance of a meeting. This is done by selecting the event and 
clicking Send Reminder button 715. Alternatively, the user 
can arrange for the reminder when the user initially creates 
the event. 
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If the recipient attaches a Free Time report (e.g., when 
declining or requesting rescheduling of the invitation), his or 
her Free Time report appears with the reply message, as 
indicated by Free Time button 721 in FIG. 7B, The Free 
Time report shows when the recipient has events booked and 
what times are free, during the next 30 days, as described 
above. It can be viewed by clicking on the Free Time button 
721, whereupon the system displays Free Time report 723, 
for the reply. The report is useful in determining an alternate 
meeting time, especially when scheduling several people. 

6. Entering Replies Manually 

For people who are invited by fax or phone, the user can 
enter the reply status manually. To enter reply information 
manually, the user selects the event from the list (in the 
Activities view). Next, the user selects the participant's 
name to bring up that individuals details in the Details pane. 
Now, the user can enter the status by right-clicking on the 
participant's name, to bring up pop-up menu 740, shown in 
FIG. 7C. Here, the user can enter: "Accepted," "Declined,'' 



the user (and others), or have been created by the user. Here, 
the user chooses the facilities and equipment he or she wants 
to reserve by selecting each item. The user can reserve 
multiple resources by clicking each one. By clicking Details 
button 801, the user can see detailed information about a 
selected resource. When finished selecting resource, the user 
clicks "Next" button 803, to proceed to the next wizard 
dialog. 

The second Resource Reservation Wizard dialog 810, 
Step 2, is illustrated in FIG. 8B. In Step 2 (Purpose and 
Time), the user enters the time and purpose for reserving the 
resource. When finished with Step 2, the user clicks Finish 
button 815, Based on the user's inputs, the Reservation 
Wizard sends out a request to book the resource for the time 
specified. The request is sent to the computer of the 
1^ resource's manager (via e-mail account) for processing by 
the SK client. A reply message is sent back to the requestor's 
computer automatically, without requiring any action by the 
resource's manager. If the resource is available, the reply 
message confirms the reservation. If the resource is 



10 



"Reschedule Requested," "Delegated," or "No Reply Yet." 20 unavailable, a message listing available times is sent instead. 

In this case, the user can reschedule by again choosing 
InternetjResourceslRcscrvation Wizard and changing the 
times as needed before re-sending the request. 
3. Adding and Distributing Resources 
The person who is going to manage the resource is usually 
the one who adds it using an Add command. This is selected 
from the system menu by choosing lDternet|Resources|Add. 
In response, the system displays Add Resources dialog 820, 
illustrated in FIG. 8C. Here, the user enters the name of the 



C. Resource Scheduling Interface 
1. General 

Resources are facilities such as conference rooms or 
equipment that the user wants to be able to schedule. The 
system of the present invention groups resources in one of 25 
the following resource types: 

1. Facilities — a resource such as a conference room or 
other immovable location. Facilities can have a Maxi- 
mum Occupancy setting. The system maintains a cal- 



endar for facilities and confirms or denies bookings 30 resource together with the e-mail type and account infor- 



automatically based on the calendar. 

2. Equipment — a movable resource such as a projector or 
vehicle. The system maintains a calendar for equipment 
and confirms or denies bookings automatically based 
on the calendar. 

3. Other — private resource which an individual user 
wants to keep track of, such as booking a conference 
call operator, or ordering catering for a meeting. There 
is no calendar for this category, and entries are recorded 
under the user's To Do items. 

Since resources typically do not have their own e-mail 
accounts, each resource has a "manager," whose e-mail is 
used to handle the calendar and messaging for reserving the 
resource. Typically, the manager is the person who creates 



mation; the latter two are automatically picked up from 
existing user preferences. The phone number field and other 
fields are included for convenience in case others have 
questions about resource reservations. The process is com- 

35 pleted by selecting Add button 821. 

After a resource has been added, it can be distributed. 
"Distributing" a resource is the process of making it avail- 
able to others for reserving. The manager distributes it to the 
users who will be reserving it. Anyone to whom the resource 

40 is distributed can distribute it to additional users. To distrib- 
ute a resource to other users, the user selects a Distribute 
command from the menu. In response, the system displays 
Distribute Resources dialog 830, illustrated in FIG. 8D. At 
831, the user clicks one or more resources that he or she 



the resource in the system of the present invention. Using the 45 manages and wants to distribute. At 833, the user selects 

e-mail account of the manager, the system handles resource users to distribute resources to. 

scheduling automatically in the background; the manager is 4. Managing Resources 

not involved in these transactions. Alternatively, a resource The system of the present invention provides tools that let 

can be given a dedicated e-mail account, whereupon the the user print resource schedules and modify or delete 

system uses it for automated scheduling of that resource, so resources from his or her system. The user can view and 

Once a resource has been added to the e-mail system (either print the schedule of any resource that he or she manages. To 

to its own e-mail account or that of another's), it is distrib- view a resource's schedule, the user chooses 

uted to others to make it available to them for booking. lnternetjResources|View. In response, the system displays 

2. Reserving a Resource Viewing Resources dialog 840, illustrated in FIG. 8E. From 

The user can request a resource reservation as part of 55 pulldown list 841, the user can select a particular resource to 

creating a group event. However, the user may want to do it view and then click to print the schedule for the resource in 

separately, in advance, so he or she can be sure the resource weekly or monthly view. 

is available before sending meeting invitations. To reserve a To modify a resource (i.e., change the properties of a 

resource without scheduling the event, the user employs a resource), the user chooses Intemet|Resources|Modify from 

Reservation Wizard of the present invention, which will now 60 the menu. This opens a Modlify Resource dialog box, which 

be illustrated. is similar to the Add Resource dialog box except that the 

To reserve a resource such as a conference room or user cannot modify the resource name. To remove a 

projector using the wizard, the user selects resource, the user chooses Internet|Resources|Remove, 

Internet! Reservation Wizard from the system menu. This selects a resource from a displayed list, and clicks 

displays the first Resource Reservation Wizard dialog 800, 65 "Remove." 

Step 1 (Facilities and Equipment), as shown in FIG. 8A. The If the user modifies or removes a resource that he or she 

dialog lists resources which have already been disU-ibutcd to does not manage, the user is affecting the local resource file 
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only. The user might want to delete a resource that he or she 
never uses, or might want to change a resource's description 
or owner information as displayed on his or her system. 
Since these changes affect the user's local system only, they 
do not affect others who also reserve that resource. If the 
user is the owner of the resource, deleting it has widen 
impact. By deleting that resource, the user removes the] 
resource's calendar, making it impossible for anyone to 
schedule that resource. If the user simply wants to stop 
managing the resource, he or she should "transfer" the 
resource. 

Transferring a resource is the act of assigning a resource 
the user owns to another manager. This is done by choosing 
Interne t|Resources|Transfer from the menu. In response, the 
system displays a Transfer Resources dialog 850, illustrated 
in FIG. 8R Here, the user selects the resource from resource 
hst 851 and then clicks Transfer button 853. The system now 
displays a second Transfer Resources dialog 860, shown in 
FIG. 8G, for entering information about the new resource 
manager. Transfer is completed by clicking Transfer button 
861. 

Internal Operation 
A, Overview of Architecture and Basic Operation 
FIG. 9 is a block diagram providing an overview of the 
internal architecture of a group scheduling system 900 
constructed in accordance with the present invention. The 
group scheduling system 900 includes a main module 910 
comprising a user interface 911, a composer 912, a parser/ 
interpreter 913, an e-mail send/receive interface 914, a 
calender interface 915, and an Activities view module 916. 
TTie user interface module 911 supports entering, editing, 
and deleting of group scheduling information. The composer 
912 is employed for actually composing a group scheduling 
message. The message itself, when it is received by another 
SK client, is parsed and interpreted by the parser/interpreter 
913. The e-mail module 914 supports the sending and 
receiving of e-mail messages and documents, using com- 
mercial available e-mail providers. The calendar interface 
915 allows the main module or engine 910 to communicate 
with a separate calendar module 920. The Activities view 
module 916 supports the previously-demonstrated user ses- 
sions in Activities View mode of operation. 

General operation of the system can be divided into two 
tasks: sending an event and receiving an event message. The 
general process of sending an event is illustrated by Send 
Event Method 1000, shown in FIG. 10. The process begins 
with the user entering event information in the user 
interface, as indicated by step 1001. The composer module, 
acting on the user information, proceeds to compose the 
event scheduling message, at step 1002, At the point of 
composing a message, the system provides a variety of 
different message types, each corresponding to a particular 
state a meeting is at. Once a message has been composed, it 
can be inserted into the calendar, as shown by step 1003. 
Thereafter, the system schedules the message to be sent via 
the e-mail transport layer, as indicated by "e-mail delivery*' 
step 1004, Once the message has been sent, the Send Event 
Method 1000 is done. 

The general process of receiving messages is illustrated 
by Receive Event Method 1100, illustrated in FIG. 11. At the 
outset, the process spawns a separate thread to receive an 
event message, at step 1101. As shown by step 1102, at a 
predetermined interval a "flash" session is initiated. During 
the flash session, the system polls the user's in- box, for 
identifying incoming scheduling messages (i.e., those hav- 
ing the signature <ISK>). 

The incoming scheduling messa ges are parsedbythe 
parser ^r913)r as_ shown at step HOT I lie j paissc-^jracts 
scheduho^ infortn ation fr om the messages; stonrig it in a n 
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th e system . T he parser iden tifies, for instance, the <ISK> 
i^ entitierTclate ' and t ime iriformation . _messa ge-type infor- 
mation (ejTS cSegine, Resch edule^-Cance L and so^o rth) , 
and't fag^ftg j[rhe pa rsed intormation is.Jn turn, passed to a 
g enSfsTinessagc handler at step 1104. In response , the 
message handler tnggers one of several actions, a s indicat ed 
b y~step~tt06, py involang more-specifitTKanaicrs — ones 
which pertorm the requ ested action. Actions include, for 
example, Scnedule New il05a7Reschedule 1105 B, Cancel 
1105c, Minutes of Meeting 1105c/, Resource Reservation 
UOSe, and the like. At step 1106, the parsed information is 
stored in the group scheduling database (950). From here, 
the information will also be employed, at step 1107, to 
^update the calendar and/or a resource manager, as needed. 
lOnce updating is complete, the method is done. 

B: Core Data Structures 

1 . Group Item and Group Attachment 

Before describing the internal methods of operation in 
further detail, it is first helpful to examine internal data 
stmctures which support operation of those methods. A 
group scheduhng item is represented internally in the system 
by a "Group Item" data structure, GROUP_ITEM. In an 
exemplary embodiment, this structure may be constructed as 
follows (using the C/C++ programming language, for 
instance). 



25 



30 



typedef struct 
{ 

DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
DWORD 
HANDLE 



dwEventtDl; 
dwEvcnaD2; 
dwEromDatftTime; 
dWToDateHine; 
dwOldFromDatcTlmc; 
dwOltrroDatcTime; 

dwScndRccciv^ 
hTexl; 

HGLOBAL hRecipient; 

DWORD IfData; 

LPGROUP^ATTACHMENT tpAttach; 

// READ_rN_MAIN; READ_IN_^MTACH; FTMPHLE; 



DWORD 


wFlags; 


DWORD 


wFlags2; 


short 


nTcxts; 


stiort 


nRecLpieats; 


short 


nPageHoxir; 


short 


nPageMin; 


BYTE 


bXypes; 


BYTE 


bTimcZonc; 


BYTE 


bLead; 


BYTE 


bLeadUnit; 


} GROUP_rrEM; // total 64 bytes 


typedef GROUP_JTEM " LPGROUP_rrEM; 



inl:grtiarfS3reseiifation suitable for use_by_^ther moclules of 



As shown, the GROUP_„ITEM data structure includes 
50 two event IDs: dwEventlDl and dwEventID2. Together, 
these comprise a 64-bit (i.e., two double words) identifier for 
each scheduling group item. This ID is employed among the 
various cUents for uniquely identifying a particular group 
scheduling item. Next, the data structure stores "from'* and 
"to" date and time information in dwFromOateTime and 
dwToDateTime data members, respectively. Additionally, 
the particular item might comprise a "reschedule" item and, 
therefore, need to store the original ("old") date and time. 
This information is stored in dwOldFromDateTime and 
dwOldToDateTime data members. The dwSendRecieve data 
member also stores dale and time information; it is 
employed as a time stamp indicating when a group item is 
sent or received. 
Following the date/time data members are two handles: 
55 hText and hRecipient. The bText data member is a handle to 
a text buffer for the subject line (e.g., 256-character string). 
The hRecipient data member, on the other hand, is a handle 
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pointing to a recipient block — a memory block storing N 
number of recipients. The lEData member serves as a pointer 
to the detailed data — that is, the data which follows the 
subject line. 

This is followed by another pointer, Ip Attach, which 
points to a group attachment data structure. The group 
attachment information is, therefore, nested within (via a 
pointer) each GROUP_ITEM record. In an exemplary 
embodiment, a "Group Attachment" data structure, 
GROUP^TTACHMENT, may be constructed as follows. 



#define ARRAY, 
typedcf struct 
{ 

WORD 



LEN 



63 



10 



15 



wFlags; // IS_MEETINGNOTE_nLE 

// if on then meeting note saved in file 
// REMtNDER_SENT 
sbort nAttachSizc; 
DWORD wReserved; 
LPSTR IpAttachFile; 

HGLOBAL hReg^rding; 20 

UINT nRegardings- 

LPSTR IpMeetingNote; 

UINT nMeetingNotes; 

char s2Location[ARRAY_LEN+l]; 

char 52City[ARRAY_LEN+l]; 
} GROUP_ATTACHMENT; // 156 bytes; 25 
typedef GROUP_AITACHMENT * LPGROUP^ATTACHMENT; 

As shown, the data structure includes as its first member 
nAttachSize, an integer storing a size for the attached file. 
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This is followed by wReserve which comprises a double 
word (DWORD) currently not used. The IpAttachFile data 
member stores a pointer to a text string comprising the name 
of the attach file (which itself is stored on disk). 

The next data member, hRegarding, is a handle pointing 
to a "regarding" structure which comprises the message 
body — that is, what the event is in "regards" to. This is 
followed by an integer data member, nRegardings, which 
stores a size for the regarding block which is being pointed 
to by the hRegarding handle. The IpMeetingNote data 
member is a pointer to a text block comprising a user- 
supplied meeting note text string. The size of this pointed-to 
data structure is stored by nMeetingNotes. Finally, the 
location (e.g., particular conference room) and city where 
the meeting or event is to occur are stored by szLocation and 
szCity character strings, respectively. 

Returning to description of GROUP_ITEM data 
member, the next data member in the GROUP_ITEM data 
structure is a double word, wFlags, storing a set of flags. The 
flags indicate various information for the group item and 
group appointment (described below), including, for 
example, whether the event is Canceled, Rescheduled, or 
Deleted. In an exemplary embodiment, the following flags 
are defined. 



// flags for GROUP_APPOINTMENT and GROUP_rreM.wFlags 



#define READ_IN_MAIN 

#define READ_IN_AITACH 
// #define FTMPFILE 

#dcfinc HAS_MEETING_NOTE 

#define EVENT_CANCELED 

#dcfine EVENT__RESCHEDULED 
// #defliie EVENT_DELETED 

#define SCHEDULED_EVENT 

#define SEND_REMINDER 

#dcfine REMINDER_SENT 

#dcfine SEND_XArER 

#dcfine NO_REPLY_NEEDED 

^define RECEIVED_EVENT 

#dcfinc EVENT^CCEPTED 

#define EVENT__DECLINED 

#dcfine UNREAD_EVENT 

#dcftnc EVENT_FORWARDED 

^define SET_^LARM 
only 

#deftne STAMP_TO_CARD 
only 

#definc ArrACH_MY_CALENDAR 
only 

#defmc RESOURCE_EVENT 

iWefine FREETIME_EVENT 

#define PERSONAL„EVENT 

#dcfinc CONFTDENTIAU-EVEm' 

#deftne PAGE_ME 

#define UNCONFmMED_JEVENT 

#dcftnc COMPLETED_EVENT 

tfdeftne UNBOOKED_EVENT 

#define EVENT_RESCHEDULE_REQUIRED 

// #definc 0x40000000 

#define EVENT_RECEIVE_FORWARD 



0x00000001 // both 
0x00000002 // both 

0x0004 //both 
0x00000008 //both 
0x00000010 // both 

0x00000020 // both dwOIdDatcTimc good 

0x00000040 //both 
0x00000080 // scheduler side 
0x00000100 // scheduler side 
0x00000200 // scheduler side 
0x00000400 // scheduler side 
0x00000800 // scheduler side 
0x00001000 // receiver side 
0x00002000 // receiver side 
0x00004000 // receiver side 
0x00008000 // receiver side 
0x00010000 // receiver side 
0x00020000 // for GROUP^PPOINrFMENT 

0x00040000 // for GROUP_APPO[NTMENT 

0x00080000 // for GROUP_^PPO[NTMENT 



0x00100000 
0x00200000 
0x00800000 
0x01000000 
0x02000000 
0x04000000 
0x08000000 
0x10000000 
0x20000000 



// receiver side 



0x80000000 // the second recipient 



The flags can be combined (i.e., bitwise "or" operation), for 
65 storing in a single double word. 

The GR0UP_1TEM data structure stores a second set of 
flags in another double word data member, wFlags2. In an 
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exemplary embodiment, these additional flags are defined as 
follows. 



// additional flags 

#define EVENT„QUEUE__rrEM QxOOOOOOOl 

^define EVENT_ISrEW_nEM 0x00000002 

mchnc EVENT_RECEIVE_RESCHEDULE 0x00000004 

#define EVENT_RECEIVE_CANCEL 0x00000008 

#defiiie EVENT_JIECEIVE_REMINDER 0x000000 10 // receiver side 

#define UNREAD_MEEnNG_NOTE 0x00000020 

#define EVENT_RECEIVE_REPLY 0x00000040 



Following the flags, the nText data member stores a byte 
count corresponding to the size of the block pointed to by the 15 
hText handle (described above). The nRecipients data mem- 
ber stores a count for the number of recipients; in an 
exemplary embodiment, up to 32,000 recipients are sup- 
ported. The next two data members, nPageHour and 
nPageMin, specify a time to page the user; this corresponds 20 
to the "page me" reminder feature previously described (for 
the Scheduling Wizard, in FIG. 5H). In an exemplary 
embodiment, the page time is specified as a time interval in 
advance of the event or meeting, such as "three hours 
before" the meeting. This serves to remind the user so that ^ 
he or she will not forget a meeting which he or she 
scheduled. 

The next data member, biypes, stores a value describing 
the item. In an exemplary embodiment, the following types 
are defined. 



// values for blVpcs in GROUP_rrEM and GROUP_APPOINTMENT 



#define 


SCHEDULE^ITEM 


1 


#define 


BROADCAST_rrEM 


2 


ffdefine 


RESCHEDULE_nnEM 


3 




REMINDER.JTEM 


4 


#dcfiiie 


FREE_TIME_rrEM 


5 


#define 


CANCEU„rrEM 


7 


^define 


REPLY_ITEM 


8 




MINUTES_rrEM 


9 


#define 


EVENT_ACCEIT_ITEM 


10 


#dcfinc 


EVENT_DECUNE_ITEM 


11 


#define 


EVENT_FORWARD_REPLY_rrEM 


12 


^define 


EVENT_FORWARD_SCHEDUL£_rrEM 


13 


#ckfinc 


EVENT_RESCHEDULE_REQUEST_tTEM 


14 


^define 


TRANSFER_SEND_ITEM 


15 


^define 


TRANSFER_ACCEPT_ITEM 


16 


#define 


TRANSFER_DECUNE_nEM 


17 


#defuie 


DISTRIBUTE_rrEM 


18 


#dcfine 


BOOK_SCHEDULE_rrEM 


19 


#deftne 


BOOK_RESCHEDUIJE_JTEM 


20 


^define 


BOOK^CANCEUJTEM 


21 


#dcfiDe 


Booie^ccEPT_rrEM 


22 


#define 


BOOie_DECLINE_rrEM 


23 



FinaUy, the bLead and bLeadUnit data members store 
information describing a "lead" time or reminder. This 
information allows the system to send reminders to all 
participants at a specified interval (e.g., three days). 

2. Each Recipient 

Each recipient involved with a group scheduling message 
is represented internally by a recipient data structure: 
EACH_REC1PIENT. In an exemplary embodiment, the 
data structure may be constructed as follows. 
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typcdef struct 




{ 




char 


szNamel32]; 


char 


szEinaLll64]; 


long 


ItD; 


long 


1ID2; 


DWORD 


wRags; // 




// 


DWORD 


wStatus; // 


long 


IfDaU; // 
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LPRECIPIENT-DATA IpAttach; 

// HGLOBAL hAttach; // a RECIFIENT_DArA structure 
} EACH_RECIPIENT, // 114 
typcdef EACFLJIECIPIENT * LPEACH_REC[PIENTi 



As shown, the first data member, szName, stores a text string 
comprising the recipient's name (e.g., "John Smith" ). This 
is followed by another text string, szEmail, which stores the 
e-mail address for the recipient. Following the recipient 
name and e-mail address are two identifier data members: 
UD and 1ID2. These IDs are used in combination to uniquely 
describe a particular recipient. 

Following the identifiers is a double word data member, 
wFlags, storing recipient flags. The recipient flags indicate, 
for instance, whether the recipient has free time, whether the 
recipient accepts or declines, and so forth. In an exemplary 
embodiment, the status flags may be defined as follows. 



As shown, the biypes data member can identify the item as 
a "Schedule" item, a "Broadcast" item, a "Reschedule" item, 
a "Reminder" item, a "Reply" item, a "Minutes" item, or the 
Uke. 

The bTimeZone data member stores an identifier uniquely 
identifying the time zone (e.g.. Pacific Standard Time) that 
the dates are relative to. In this manner, the recipient user's 
system can automatically convert the times, if desired, to 
those relative to the time zone for that recipient. In a 
preferred environment, each appointment has its own time 
zone — typicaUy, the time zone in which the item was 
originally scheduled. The recipient systems convert this 
information to and from their own relative time zones, as 
needed. 



// type of e-mails, fax, oi page in EACH_RECIPIENT structure 



55 #define TYPE_E-mail AOL 0x0001 

#definc TYPE_E-maiL_COMFUSERVE 0x0002 

#define TYPE JB-mail_EXCHANGE 0x0004 

Wcfinc TYPE_E-mail_INTERNET 0x0008 

#define TYPE_FAX 0x0010 

#define TYPE.J'AGE 0x0020 

#define TYPE_PH01SfE 0x0040 

^° #define TYPE_>1AILING_UST 0x0080 
// type of recipient 

#define TYPE_PARTiaPANT 0x0100 

^define TYPE__CC 0x0200 

#defme TYPE^ROOM 0x0400 

#dcfme TYPB_EQUIPMENT 0x0800 
65 // also, TYPE_OTHERS defined below 
// misc. flags 
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#define 


IS_SENDER 


QxlOOO 


#define 


IS_SELF 


0x2000 


#define 


HAS_REaPIENT_DATA 


0x4000 


#define 


READ„IN_RECIPIENT_DATA 


0x8000 


#dcfinc 


F_UST_DIKrY 


0x00010000 


#defme 


TYPE_OTHERS 


0x00020000 


#define 


CARD_ID_SET 


0x00040000 


#dcfinc 


TYPE_PAGE_>1E 


0x00080000 


#defiiie 


RECIPIBNT_RECEIVED_FORWARD 


QxOOlOOOQO 


^define 


RECIPIENT_SENT_FORWARD 


0x00200000 


// Recipient status flags 




// #define RECIPIENT^^ATUS 


0x0001 


#definc 


RECIPIENT^EE^TIME 


0x0002 


#defme 


REaPIBNT_FORWARD 


0x0004 


#define 


RECIPIENT_E-inai!_ADDRESS 


0x0008 


#define 


RECIFIENT_NAME 


QxOOlO 


#define 


RECIPIENT_CARD_ID 


0x0020 


#dcfinc 


RECIFIENT_MAIL_STArUS 


0x0040 


#define 


RECIPIENT_ACCEPT 


0x0080 


#define 


RECIPIENT_DECUNE 


QxOlOO 


#define 


RECIFIENT_RESCHEDULE_REQUIRED 


Qx0200 


#d£fme 


RECIPIENT_RESOURCE_CONFUCr 


0x0400 


#dcfinc 


RECIPIENT_RESOURCE_TRANSFERRED 


0x0800 


#define 


RECIPIENT_RESOURCE_Nar_FOUND 


QxlOOO 


#define 


RECrPIENT_RESOURCE„CANCELED 


0x2000 


// flags for resource events (from 0x00010000 to 0x80000000) 


#define 


RECEIVE_DISTRIBUTE_RESOURCE 


QxOOOlOOOO 


#defiiie 


RECEIVE_BO0K_RESOURCE 


0x00020000 


^fine 


SENT_B0OK_RES0URCE 


0x00040000 


#defiiie 


RECEIVE_TRANSFER_RESOURCE 


0x00080000 


/ktefine 


SENT_TRANSFER_RESOURCE 


QxOOlOOOQO 


#defiiie 


TRANSFER_SUCCESSFUL 


0x00200000 



As shown, the information indicates the type of 
delivery — e-mails, fax, or page — desired for a particular 
recipient, thereby supporting methods for communicating 
with all types of recipients, other than just e-mail. For e-mail 
types, support is provided for multiple providers, including, 
for instance, America On-line (AOL), CompuServe, 
Microsoft Exchange, and the Internet. For a recipient to be 
contacted via phone (i.e., type is TYPE_PHONE), the 
system adds an item to the user*s "call list" — that is, a list 
of calls the user is to make (as shown at 440, in FIG. 4), A 
delivery type of "mailing list" indicates that the system is to 
process multiple recipients according to a mailing list. 

The flags also indicate a recipient type. A recipient can be, 

for instance, a "participant" (i.e., type is TYPE 

PARTI aPANT) — someone who is required to reply. A 
"CC recipient (i.e., type is TYPE_CC), on the other hand, 
is not required to reply. Other types of "recipients" include 
"room," such as a conference room, and "equipment," such 
as a projector. Finally, a recipient can be simply set to 
"others" for indicating that the recipient is other than that 
above. 

As a group scheduling item is associated with a list of 
recipients, it is helpful to further characterize recipients. In 
this regard, a "sender" flag (type is IS_SENDER) is 
employed for indicating that the recipient is actually the 
sender. A "self* flag (type is IS„.SELF), on the other hand, 
indicates that the recipient is "self' — that is, the same 
individual as the user. Other recipient-type information 
serves to further characterize the recipient. For instance, the 
"page me" flag indicates that this recipient is to be paged. A 
"sent forward" flag, on the other hand, indicates that this 
recipient has delegated the item to another user. 

Finally, the recipient flags store status information for 
each recipient. Status includes, for instance, infonnation 
indicating whether the recipient accepted or declined the 
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invitation, or whether the recipient required rescheduling. 
Additionally, at this point, flag infonnation is stored for 
resources, such as information indicating that the resource is 
not found, that the resource has been transferred, that the 
^ resource has been canceled, or that a conflict for the resource 
exists. 

Returning to the description of the EACH_RECIPIENT 
data structure, the next data member, IfData, is a pointer to 
30 a data block for the recipient; the data block stores free time 
information and a short message for the recipient. Finally, 
the EACH_RECIPIENT data structure stores a pointer, 
IpAttach, which points to a RECIPIENT_DATA structure. 
This structure will now be described. 
3. Recipient Data 

The RECIPIENT_DArA structure stores free time and 
reschcduhng infonnation for a particular recipient. In an 
exemplary embodiment, the data structure may be defined as 
20 follows. 



typcdcf struct 
{ 

DWORD dwFlags; // Reserved •- not used 
25 long IStart; 

long lEnd; 

DWORD dwRcschcdulcStartl3l // reschedule request start 

datcytime 

DWORD dwRescheduleEiid[3l; // rescliedule request end 

date/ time 

30 LPSTR IpMsg; 

LPSTR IpFreeTimc; 
void * IpNext; 
} REaPtENT_DATA; 

typedef RECIP[ENT_DATA * LFRECIPIENT_DATA; 



As shown, the first data member, dwFlags, comprises a 
double word data member storing flag or status information; 
it is cunently not used. The next two data members, IStart 
and lEnd, indicate a free time range (e.g., next 30 days). 

40 Then, the next two data members, dwRescheduleStart and 
dwRescheduleEnd, store information specifying a resched- 
ule request start date/time and reschedule request end date/ 
time, respectively. As each of these data members comprises 
an array of size three, these data members actually indicate 
three rescheduling alternatives. 

The next data member, IpMsg, comprises a pointer to a 
text string storing a message associated with the reschedule 
request (e.g., "Sony, I am in Chicago next week; please 

50 reschedule."). This is followed by a pointer, IpFreeTime, 
which points to a block describing the free time for the 
recipient (i.e., information employed for displaying a Free 
Time report for this recipient). Finally, the data structure 
includes a "next" pointer, for pointing to a subsequent 
REaPlENT_D ATA structure. 

Each RECIPIENT„DATAslnicture, when saved to file, is 
associated with a header: REaPIENT_DArA_HEADER. 
In an exemplary embodiment, the header may be con- 

60 structed as follows. 



^pcdef struct 

DWORD dwFlags; 
UINT nMsgs; 
UINT nFrecTimes; 
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long IStart; 
long lEnd; 

DWORD dwReschcdulcStart[3]; 



// 



DWORD dwRcschcdulcEndU]; // 

} REaPIENT_J)ArA_HEADER; 
typcdcf RECIPIENT_DArA_HEADER ' 
LPRECIPIENT_DArA_HEADER; 



rescbedute request 
start date/time 
reschedule request 
end dat^iime 



The header includes data members the same as or similar to 
those described for RECIPIENT_DATA. Additionally, the 
header stores a number of messages, nMsgs, and a number 
of free times, nFreeTimes. 

Also stored is a footer: RECIPIENT_DArA_FOOTER. 
This may be constructed as follows. 



typedef struct 
{ 

DWORD IfData; // -1 if no next item. 
} REaPIENT_DATA_FOOTER; 
typedef RECIPIENT_DArA_HEADER ' 
LPREaPIENT_DATA_HEADER; 



The footer simply comprises a single data member, IfData, 
which serves to indicate whether a "next" recipient data item 
exists (in a chain of recipient data records). 
4. Group Appointment 

At run time, a memory block or buffer is allocated for 
storing context information. This buffer is organized into a 
GROUP_APPOINTMENT structure, for describing a par- 
ticular group appointment. In an exemplary embodiment, 
this data structure may be constructed as follows. 



25 



typedef struct 




DWORD 


dwEvenUDl; 


DWORD 


dwEvcntID2; 


DWORD 


dwFromDa teTlme; 


DWORD 


dwTbDateTime; 


DWORD 


dwOldPromDateUme; 


DWORD 


dwGldToDatcTime; 


DWORD 


dwRcschcdulcSUrt(3]; 


DWORD 


dwRescheduleEnd[3]; 


DWORD 


dwSendRcceive; 


HANDLE 


hitxt; 


HANDLE 


h Regarding; 


HANDLE 


hRedpient; 


LPSTR 


IpMeetingNole; // meeting note file name 


LPSTR 


IpShortMsg; 


LPSTR 


IpDclcgatcMsg; 


LPSTR 


IpFieelime; 


int 


nIsDelegate; /' 


int 


nlsRcsource; ( 


HANDLE 


h Forward; \ 


WORD 


nitxts; 


WORD 


nReg^dings; 


WORD 


nRedpients; 


DWORD 


wFlags; // READ_IN 


DWORD 


wFlags2; 



30 
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short nPageHour, 

short nPageMin; 

BYTE bLeadHoun 

BYTE bLeadMin; 

BYTE bReoainderLcad; 

BYTE bReminderUnit; 

BYTE bTimeZone; 

BYTE bTypcs; 

int nTone; 

DWORD IfData; // 42 

int nResourceStatus; 

char fizResouxceName{64]; 

char 5zLocation[64]; 

char szCity[64]; 

char 6zSenderN&me[32]; 

char szSenderE-mail[ 64]; 

int nSenderE-main^e; 

char szAttachFilcl PAmMAX+4]; 

EACH_RECIPIENT PageMe; 

HGLOBAL hPlaceList; 

int cPlaceUsts; 

// LPSTR IpTZ; 

n int nTZs; 
} OROUP^PPOINTMENT, // total 136 bytes 
typedef GROUP_APPO[NTMENT * LPGROUP_APP0INTMENT^ 
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This temporary, in-memory data structure (i.e., it is not 
saved to disk) largely comprises data members taken from 
the previously-described data structures. Additionally, 
however, the data structure stores information further 
describing any delegation. For instance, the IpDelegateMsg 
data member points to a delegate message text string. This 
allows one recipient to send a message to a dele gated -to 
recipient, yet not have that text string message returned to 
the originator of the invitation. Additionally, delegation is 
supported by the szSenderNamc and szSenderE-mail data 
members. This information indicates who the delegated to 
recipient should respond to- — that is, the originator of the 
invitation. 

Group Scheduling Methodology 
1. Schedule Group Event 

With an understanding of the internal day structures 
employed, methods of operation may now be examined in 
further detail. Group scheduling begins with a request to 
schedule a group event. This request results from user input 
occurring at the user interface, as illustrated at step 1001 in 
FIG. 10. Actual operation of the user interface itself, such as 
processing menu selections and user input at edit fields, may 
be done in a conventional manner using standard windows 
graphical user interface (GUI) methodology. 

Once the user inpu t ^has^ culminated in ^ r eq uest t o 
sc hedule a group_eyent, the request isjjrocesscd by the grou p 
s c^e3uling| module or engine 910 (of FIG. 9). This module 
internally invokes a Schedule__Group_Event method. In an 
exemplary embodiment, the Schedule_Group_Event han- 
dler or method may be constructed as follows (again, using 
the C/C++ programming language). 



1: / ■ 

2: Schedule a following type of group events: 

3: - Normal group event (reply required) 

4: - Broadcast group event (no reply needed) 

5: - Reminder 

6: - Reschedule 
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7: - Free time 

8: - Cancel meeting. 

9: * * 

10: int Schedule_Group__Event CLPGROUP_^PP0IIsrrMENrr IpNew, 

11: int nAddlbList, int nAdcTTo Appointment, int nFromCalcndar, 

12: LPSTR IpInBuf, int nInSize) 

13: { 

14; GROUP^TTEM Groupltcm; 

15: LPSTR IpMessagc - IpInBuf; 

16: int nindcx - -1; 
17: 

18: if (UpMessage) 

19: { 

20: IpMessagc = AllocLockBufferPtr (NOTETEXTStZE * 3); 

21: nInSize - NOTETEXTSIZE * 3; 

22: ] 
23: 

24: if (llpMcssagc) 

25: return FALSE; 
26: 

27: nstartOroupEvent - TRUE; 
28: 

29: II Save to appointment liat in Calendar module. 

30: if (IpNcw — >hRecipienl && IpNew — >nRecipients) 

31: { 

32: // get send and receive time. 

33: if (IpNew— >b'IVpes == SCHEDULE_rrEM || IpNew— >b1Vpes 

34: " — BROADCAST_ITEM 1 | IpNew— >bTVpes 

35: == RESCHEDULE_JTEM | [ IpNew— >b'IVpes == CANCEUJTEM) 

36: time (&(lpNew — >dwSendReceive)); 

37: 

38: // - add call items to call lisL 

39: if (IpNew— >bTVpes SCHEDULE_rrEM 

40; 1 1 IpNew— >bTypes == BROADCAST_JTEM) 

41: Insert_Calls_Calendar (lpNew>, 

42: 

43: // - add send letter to todo list. 

44: if (IpNew— >b'IVpes - SCffiDUUE_[TEM 

45: 1 1 lpNew^>bTypcs = BROADCAST_JTEM) 

46: Insert_Todos_Calendar (IpNew); 

47: 

48: // add/edit/deletc calendar item 

49: if (InFromCalendar) 

50: { 

51 : if ((IpNew— >bTypes — SCHEDULE_rrEM 

52: 1 1 IpNew— >bTVpe3 — BROADCAST_ITEM) 

53: && nAddlb Appointment) 

54: { 

55: if (! (IpNew— >wRag5 & UNB0OKED_EVENn) 

56: AddNewAppoLntment_FromGROUP (IpNew); 

57: // AddNewGroup Appointment (IpN^w); 

58: } 

59: else if (IpNew— >bTVpes RESCHEDULE_JTEM) 

60: { 

61 : // mm Reschedule Appointment 

62: ChangeExiiitAppoLntment_FromGROUP (IpNew); 

63: } 

64: else if (IpNew— >b'IVpes == CANCEL_rrEM) 

65: { 

66: // mm delete appointment 

67: DeleteExistAppointment_FromGROUP (IpNew); 

68: } 

69: } 

70: 

71: // add item to GROUP event data base. 

72: if (nAddToList) 

73: { 

74: RcsolveAllMailingLists (IpNew); 

75: if(!GROUP_^ppointment_'Ib_GROUP_Item(lpNcw, AGroupItem)) 

76: { 

77: UnlocIcFreeBufferPtr (IpMessagc); 

78: return FALSE; 

79: } 

80: GroupItem.wnags =- READ_IN_MAIN | READ_[N_ATIACH; 

81 : Group Item. wFlags =- SCHED ULED_EVE^^^ 

82: GroupItem.wFlags2 =- EVENT_QUEUE_rrEM; 

83: if (IlaBroadcastType (&GiDupItem)) 

84: { 

85: ResolveAJlExchangcMailingLiflta (&GroupItem); 

86: ) 
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87: 

88: ScanFoiSelCSctAccept (&GroupItem); 

89: // actual call to add item to GROUP event database 

90: nindex 

91: - AddOncGroupItcm ( NULl^ AGroupItcm, 

92: SCHEDULED_EVENT, 
93: Get Current_SortFIag ( )); 

94: // . . . DEBUG 

95: } 

96: // empty else case . . . 

97: // Now COMPOSE MESSAGE 

98: if (!(lpNew— >wFlags & SEND_LArER)) 

99: { 

100: if (IpNew— >bTypes == SCHEDULE_rrEM) 

101: { 

102: CotnposeScheduIeMessage OpNew, 

103: MSG_SCHEDULE, IpMessage, nInSize); 

104: } 

105: else if (IpNew— >bIVpes « BROADCAST_JTEM) 

106: { 

107: ComposeScheduleMessage (IpNew, lvlSG_BROADCAST, 

108: IpMessage, nInSize); 

109: } 

110: else if GpNew— >bTVpes « REMINDER^JTEM) 

111: { 

112: ComposeScheduleMessage (IpNew, MSG__REMINDER, 

113: IpMessage, nInSize); 

114: bIsReminderMsg - TRUE; 

115: } 

116: else if OpNew— >b'IVpcs « RESCHEDULE ITEM) 

117: { 

118: ComposeScheduleMessage (IpNew, MSG_RESCHEDULE, 

119: IpMessage, nlnSize); 

120: } 

121 : else if (IpNew— >b'IVpes — CANCEL_JTEM) 

122: { 

123: ComposeCancelMessagc (IpNew, IpMessage, nInSizc); 

124: } 

125: 

126: // - tend email; 

127: S6ttd_A0L,_Email (IpNew, IpMessage); 

128: Send_CompuServe_Email (IpNew, IpMessage, FALSE); 

129: Send_Exchange_Email OpNew. IpMessage, FALSE); 

130: Seod_Internet__Email (IpNew, IpMessage, FALSE); 

131: 

132: 

133: // - send fax; 

134: Seiid_Group_Fax (IpNew, IpMessage, FALSE); 

135: 

136: if ((IpNew— >bTypes — SCHEDULE_rrEM) | | 

137: (IpNew— >bTypes =- BROADCAST_rrEM) | | 

138: (IpNcw— >b'iypcs — RESCHEDULJE_rrEM) | | 
139: (IpNew— >b'iypes == CANCEL_JTEM)) 
140: { 

141: int nLea • Istden (IpMessage); 

142: 

143: Loadstring (hCardfilelnstance, 

144: IDS_THIS_JS_RESOURCE. IpMessage + nUn, BUF_LEN); 

145: 

146: Send_CompuServe_Email (IpNcw, IpMessage, TRUE); 

147: Send_Exchangc Email (IpNew, IpMessage, TRUE); 

148: Send_Intcriict^Email (IpNew, IpMessage, TRUE); 

149: Send_Group_Fax (IpNew, IpMessage, TRUE); 

150: } 
151: 

152: // - fiend page; 

153: Sciid_Group_Page (IpNew, FALSE); 

154: bIsReminderMsg » FALSE; 

155: } 

156: £scheduledDiity - TRUE; 

157: } 
158: else 
159: { 

160: AddNewAppoinlmcnt FromGROUP (IpNcw); 

161: } 

162: if(!IpInBuO 

163: UoloctFrccBufiferPtr OpMessage); 
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164: nStartGroupEvcnt » FALSE; 
165: 

166: return TRUE; 
167: } 



(line numbers added above to aid in the following description) 



This method is invoked after the user has completed UI 
data entry. It serves to schedule one of the following types 10 
of group events: Nonnal group event (reply required), 
Broadcast group event (no reply required). Reminder, 
Reschedule, Free Time, or Cancel meeting. 

The parameters required for the method are set forth at 
Uncs 10-12. The lirst parameter, IpNew, re ferences a n ew 15 
group appomtment data structure (described abo ve). Th e 
s econd p arameter, nAddloD st, i ndicates ttTa T'this ^oji p 
event snouja be ad ded to t he group ^ sche dul ing database . The 
th ird parameter, nkHSToAppomtment, indicates whethej tEe 
event should be added to the use r'js a pE^ointmcnt s (l isted in 20 
ihe user's caiendarj . J tie t'o urtn parameter, nFromCalcnd ar 
i ndicates' that this request is ongin ating from the user's 
c alendar, for example, as a result of a drag-and^ rop event 
occu rring in the calendar. The first two parameters, IpnBuff 
a nd nSize, characterize a passed-in memory buffer; t he 25 
memory buffer is typically used for stonng message strm gs. 
At lines 14-16, the method initiaUzes local (stack) va riables. 
At lines 18-25, the method attempts to allocate a memory 
buffer for storing a message. If a buffer cannot be success- 
fully allocated, the method returns "false" at line 25. At line 30 
27, the method initializes a global variable, 
nStartGroupEvent, to the value of "true." 

Starting at line 29 ^ the method will undert ake to save the 
group event to the appointment list in tne cai entfSrmodule. 
Tf^lfi f^nr^^r<^ fniif^y^g^t li ne;3U, th e method t<^is wneTner 35 
there are recipients— that is . whetEgf ims is a "group" 
appointment. Otherwise (i.e., the_^condition at Hne, 30 is 
(false), the event is in ptead a "loca l!!, appointment. Betw een 
l ines 32 and 69, the method tests group appointment flags for 
deter mining its course of action. At lines 32-36, for insta nce « 40 
i Fthe event is a "Schedule" item, a "Broadcast" item , a 
" Reschedule" item, or a "Cancel" item, the _pre yiouslv- 
de scribed dwSendRecieve time stamp is updated at line 3 6. 
At lines 38-41 j, the method adds a Schedule or Broadca st 
it em to the user*s c a ll Ust. In a 'similaLjna'nn'er/ at lin es 45 
4^-46. the metbodiHcIs a Schedule or Broadcastitcm to the 
u ser*s "tod^;" li st . The "insert calendar" call serves to call 
inlo ^fijiakarl u modnlf^ 020 (nf FIG .9) - 
""Slines48^9, the method tests whether the event request 
originated from the calendar. If not, then the method must 50 
add the event to the appointment list, if the requested event 
is a Schedule or Broadcast item. Specifically, the method 
invokes an AddNewAppointment_From GROUP subrou- 
tine at line 56. Otherwise, the method tests whether the event 
is a Reschedule item (at line 59) or a Cancel item (at line 64). 55 
For a Reschedule item, the method changes the existing 
appointment, at line 62. For a Cancel item, on the other 
hand, the method deletes the existing appointment, at line 
67. 

At lines 71-95, the method undertakes to add the event 60 
item to the group scheduling (event) database 950 (of FIG. 
9). Specifically, the method tests the nAddlbList parameter, 
at line 72. If this is set to "true" (i.e., greater than 0), the 
method proceeds to convert the group appointment into a 
group item, resolving all recipients on any mailing lists. The 65 
actual call to add the item to the database occurs at lines 
89-93, where one group item is added. 



Starting with line 97, the method will now undertake 
composing of the message for notifying recipients of the 
group scheduHng event. At line 98, the method tests a 
SEND— LATER flag, which indicates whether the schedul- 
ing message is to be sent later. If the message is not to be sent 
later (i.c., the "if statement at line 98 evaluates to "true'*), 
then the group scheduling event message must be composed 
now. In such a case, the method will proceed to compose and 
send a message, at lines 99-155. Steps of the method for 
composing and sending the message will be described next. 

Lines 100-124 set forth a sequence of "else if* case-like 
statements which switch on the item type. At line 100, for 
instance, if the item is a Schedule item, the method invokes 
the composer at lines 102-103, for composing a Schedule 
message (MSG_SCHEDULE). If, instead, the item is a 
Broadcast item, tested at Une 105, the method invokes the 
composer at lines 107-108, for composing a Broadcast 
message (MSG— BROADCAST). For a Reminder item, 
tested at line UO, the method invokes the composer at lines 
112-113, for composing a reminder message (MSG_ 
REMINDER). For a Reschedule item, tested at line 116, the 
method invokes the composer at lines 118-119, for com- 
posing a reschedule message (MSG_RESCHEDULE). 
Finally, if the item is a Cancel item, tested at line 121, the 
method invokes the composer at line 123, for composing a 
cancel message. The foregoing steps, therefore, invoke an 
appropriate handler in the composer 912 (of FIG. 9) for 
creating an appropriate message. The message itself is stored 
in the memory buffer pointed to by Ip Message — the memory 
buffer allocated at lines 18-25. After the task of composing 
the message is done, the method proceeds to send the 
message using the appropriate transport for each recipient. 

At lines 126-130, the method invokes the e-mail module 
or manager for transporting the message over available 
services: America On-Line (handler invoked at line 127, 
CompuServe (handler invoked at line 128), Microsoft 
Exchange (handler invoked at line 129), and Internet 
(handler invoked at line 130). As shown, each handler 
invocation passes a pointer to the GROUP_ 
APPOINTMENT data structure as well as a pointer to the 
message buffer (which holds the just-created group sched- 
uling event message). As shown, a Boolean parameter is 
passed with the value of "false" for indicating that the 
message is not for a resource (which requires a slightly 
different format). For each handler invocation, the e-mail 
module will enumerate the recipients for the respective 
services and post group scheduling event messages accord- 
ingly. 

At lines 133-134, the method invokes a fax handler for 
sending facsimile transmissions to the recipients which are 
preferably reached via that mechanism. Faxing from the 
computer can be done in a conventional manner, using a 
"Fax modem"' and built-in Fax support (e.g., in Microsoft 
Windows® 95, available from Microsoft Corp. of Redmond, 
Wash.). 

At lines 136-150, the method essentially repeats the 
foregoing steps of invoking e-mail and fax handlers, except 
that here the process is undertaken for a resource. The 
process is essentially the same except that at lines 141-144 
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the method modifies the just -created message (stored in the 
memory buffer) for adding an identifier indicating that the 
group scheduling event is for a resource. At lines 152-153, 
Sie method invokes a SendGroupPage handler for process- 
ing any request to page a recipient (or the user himself or 
herself). At lines 154 and 156 local cleanup is performed. 

At line 158, an "else" statement is defined. This statement 
is reached in the event that the message is to be sent later 
(i.e., the "if* statement of line 98 evaluates to "false"). In 
such a case, the method simply adds a new appointment, at 
line 160. Steps are not undertaken at this point to compose 
and/or post a group scheduling event message. Finally, the 
method performs local cleanup, such as freeing the message 
buffer, at lines 162-163. After resetting the nStartGroupE- 
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calendar with the embedded calendar. The synchronization 
generic in nature, so that it can be extended to any data 
object which is capable of synchronization. 

5 b. Message Body 

Following the signature and message-type is (if required) 
a message body. Here, the system includes specific data 
items which characterize the scheduling event. The message 
10 body for Schedule and Broadcast message-types is exem- 
plary in this regard. In an exemplary environment, a mes- 
sage body for these message -types may be constructed as 
follows: 



<Froin Date Timo 
<lb Date Timo 
<Location> :- 

<aty> 

<Time Zono 
<Attributc5> 
<EventIDl > 
<EventID2> 
<Subjcct> 
<Message Content> 



YY/MM/DD HH:MM 
YY/MM/DD HH:MM 
Place name where the meetiDg will be held 

City name where the meciing will be held It is related to Time Zone. 
<'nme zone name where appointment time is based on> 
<Alarm> 

A unique ID for the event. 
The second part of the ID. 
<Me5Sage tcxt>'<;/Subject:» 
<Regarding text><;/Messagc Content> 
"Name; Email address; EmaU Type" "Name; Email Address; 



<Participanta> 

Email Type" <;/Participants> 
<CC> "Name; Email address; Email Type" "Name; Email Address; Email Type" 
</CC> 

<:Room> : = "Name; Email address; Emai] Type" "Name; Email Address; Email Type" 
</Room> 

<Equipment> := "Name; Email address; Email Type" "Name; Email Address; Email 
Type" 

</Equipinent> 



vent global flag, at line 164, the method returns "true," at As shown, the message body includes data items which 

line 166, whereupon the method is completed. 35 correspond to the previously-described internal data struc- 

2. Composing Messages tures. For instance, the group scheduJing event is character- 

To understand methotb of the present invention for com- ^ ^ ^ „ j^^^„ ^ ^^^^ ^ ^ ^^^^^ ^ ^. 
posmg messages, it is helpful at the outset to examine group . , . • • . -.^ , . 

scheduling formats employed by the system for creating ^ ^^^^ ^0°^' ^h^ ^^^^1^ ^ identified by the 

messages. In general, messages are created using delimiters, 40 previously-descnbed two-part event ID. The message body 
thereby, avoiding position dependency of particular infor- concludes with a list of e-mail addresses, including 
mation within a message, addresses for participants, "CC* recipients, and resources 

a. Message Formats (divided into "room" and "equipment" subtypes). Each of 

In an exemplary environment, every message mcludes a ^^^^ ^^^^ ^tems may comprise a list of e-mail addresses, 
signature and a message type, which may be constructed as 

follows: The message body for a reply message, on the other hand, 

is constructed as follows. 

<ProdiKl SigDature> :- <ISK> (or <SIS>) 

<Message TVpe> :« cSchedule\Broadcast\Reply\Frce Time\ „ , „ . 

Rcmind«\R«ch=dulc\McelingNotrtC.«el\Rec«rrmg\NewR«oura\ 50 f'P'^?^"* <Aocepl\DecJu.o\Re«:hedule Rcqu.rod\Sleep\ 

R«ou™\Aciio»\SyachroDiz.Uon> Fo.war<iU»esou,ce\Free Time* 

[ <Forward Tb> :- <Name; E-mail address; Email TVpe> 

^/Forward Tb> 

As shown, the message includes the previously-described :^rDattmer :^ YY/mm/dd hh:MM 
signature followed by a particular message-type. The ^ib Date Timo :- YY/MM/DD HH:MM 

message-type itself can be any one of the following: 55 » 

Schedule, Broadcast, Reply, Free Time, Reminder, <EvcntiDi> a unique id for the evenu 

Reschedule, Meeting Note, Cancel, Recurring, New -n^*^ P^^i of the id. 

_ -i i . 1 . . . ™, <Short Message> > <Short text messagex/Short Mcssago 

Resource, Resource, Action, and Synchronization. The 

"Action" message -type supports workflow applications. 

Here, the message serves as a "to do" item or task for one 60 



or more recipient users. The "Synchronization" message, on message body includes data items corresponding 

the other hand, serves to synchronize two or more data the previously-described data members in the group 

objects, such as user calendars. Recall that a data object scheduling internal data structures. A reply includes, for 

characterizing a calendar (e.g., free time data object) can be instance, a reply type, such as "Accept," "Decline," 
imbedded within a message. A Synchronization message- 65 "Reschedule required," or the like. In the event that the 

type, therefore, exchanges calendars and instructs the recipi- replying user has delegated the event, the delegated-to user's 

ent system to automatically synchronize the recipient's address is provided in the "forward to" field. If the reply 
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request rescheduling, rescheduling date and time informa- 
tion is included. For this type of message, the message also 
includes a file attachment providing further information for 
(e.g.. Free Time report). Finally, the message includes the 
two-part event ID, so that the reply can be matched up with 
the original invitation. Any message provided by the reply- 
ing user is transmitted in the message field, "short message." 



36 



The "sleep" message -type is provided for those users who 
are on vacation. Exemplary message bodies for other mes- 
sage types are appended herewith as Appendix A. 
c. Methodology for Composing Messages 
In an exemplary environment, a method for composing 
scheduling event messages, ComposedScheduledMessagc, 
may be constructed as follows. 



2: This function is called for schedule a: 

3: - Schedule meeting 

4: - Broadcast meeting 

5: - Reminder 

6: - Reschedule 

7: 

8: Meeting message format is: 
9: 

10: <Message Typo message type name\An 

11: <01d Date Time> yy/mm/dd hh:mmVr\n (if it's a reschedule meesage) 

12: <From Date rime> yy/mm/dd hh:mmVr\ti 

13: <To Date Time> ■ yy/mm/dd hh:mm\r\n 

14: <LocatLon> location name\An 

15: <Hme Zone> time zone value\r\n 

16: <Attributc8> "attribute" "attribute*' . . . Vr\n 

17: <EvcntIDl> EvcntlDl value 5tring\r\n 

18: <EventID2> EventID2 value string\r\n 

19: <Subject> Tkxt body<;/Subject>\r\n 

20: <Me5sagc Content? Regarding body</Mcssage Contcnt>\r\n 

21: 

22: 

23: * 

24: int Con^oseScheduleMessage (LPGROUP_APPOINTMENTlpGroup, 

25: int nMcssageTypc, 

26: LPSTR IpMessage, 

27: int nSize) 

28: { 

29: char s2Field[BUF_LEN+l], szSpace[2], 

30: 5zReUirn[5], 52Timc[BUF_LEN+l]; 

31: int nIsReschedule = FALSE, nIsBraadCast = FALSE; 

32: LPSTR IpBuf; 

33: BYTE bTVpcs; 

34: 

35: szSpacelO] = ' '; 

36: szSpacejl] =0; 

37: GetReturnNewline (szRetura); 

38: 

39: if ({nMessagctVpe — MSG_DISrrRIBUTE_RESOURCE) 

40: II (nMcssageiype — MSG_TRANSFER_RESOURCE)) 

41: { 

42: LoadGenericHeaderMessage (IpMessage); 

43: } 

44: else 

45: { 

46: if (nMcssagcType = MSO_SCHEDULE | } 

47: nMessageiype MSG_REM1NDER j | 

48; nMcssageiype « MSG_BROADCAST [ | 

49: nMcssagcTVpe == MSG_RESCHEDULE) 

50: Load_ISK__Message_Headei (IpGroup, IpMessage, aSize); 

51: } 

52: 

53: 

54: r 
55: 

56: This message was generated by Internet Sidekick. 

57: "If you have Internet Sidekick installed on your system: 

58: - Please ignore this message and do not delete it Crom you inbox. 

59: • Internet Sidekick will automalicaUy process it next time you 

60: Send/Receive messages or during the next scheduled Flash Session. 

61: 

62: "If you do not have Internet Sidekick: 

63: - You can reply to this invitation using your e-mail software. 

64: Type an X next to cither Accept or Decline below, so it reads 

65 : [X] Accept or [X] Decline. 

66: - You can also enter a short message as part of your reply to the 

67: initiator in the blank section between <BEGIN REPLY MESSAGE? and 

68: <END REPLY MESSAGE?. 

69: - When you reply from youj E-mail product, make sure that the reply 

70: includes the whole original message body induding the section 
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-continued 



71: 
72: 
73: 
74: 
75: 
76: 
77: 
78: 
79: 
80: 
81: 
82: 
83: 
84: 
85: 
86: 
87: 
88: 
89: 
90: 
91: 
92: 
93: 
94: 
95: 
96: 
97: 
98: 
99: 
100: 
101: 
102: 
103: 
104: 
105: 
106: 
107: 
108: 
109: 
110: 
111: 
112: 
113: 
114: 
115: 
116: 
117: 
118: 
119: 
120: 
121: 
122: 
123: 
124: 
125: 
126: 
127: 
128: 
129: 
130: 
131: 
132: 
133: 
134: 
135: 
136: 
137: 
138: 
139: 
140: 
141: 
142: 
143: 
144: 
145: 
146: 
147: 
148: 
149: 
150: 



below the heading, For Interncl Sidekick Use Only. Also do not 
modify or delete the Subject of this e-mail message. 

- For further information on how to procure it, please visit 
Starfish Software's web site at: 

<http ://www,5tarfishsQf twarc.com >. 



Message From: (Initiator) 
Date/Tune: {Date/Time} 
Duration: {Duration} 
Time Zone: {Time Zone} 
Location: {Location} 
City/Countiy: {City} 

Subject: {Subject} 
Message; {Message} 



<BEGIN REPLy> 
Your Reply: 

[ ] Accept 
[ ] Decline 
<END REPLY> 

Reply Message: 

<BEGIN REPLY MESSAGE> 

<END REPLY MESSAGE> 

The section below is for Internet Sidekick Use Only. 
Please, do not edit or delete any of the information 
below this line. 



// append cMessagc Type> and space 
LoadString (bCardfUcInatancc, 

1DS_SKWGR0UP_MESSAGE_TYPE_ID, 

lpMessage+l6trlen(lpMessage)j aSize); 
Istrcat (Ip Message, szSpace); 

// append Schedule, Broadcast, Reminder, Reschedule 

switch (nMessageiype) 

{ 

case MSG_SCHEDUUE: 

LoadString (hCardfilelnstance, 

[DS_SKWGROUP_SCHEDULE, szField, BUF„LEN); 

break; 

case MSG_BROADCAST: 
LoadString (hCardfilelnstance, 

IDS„SKWGROUP_BROADCAST, 
szField, BUF„LEN); 
nIsBroadCast - TRUE; 
break; 

case MSG_J<EMINDER: 

LoadString (hCardfilelnstance, 

[DS_SKWGROUP_REMINrDER, szField, BUF_LEN); 

break; 

case MSG_RESCHEDULE: 
LoadString (hCardfilelnstance, 

[DS_SKWGROUP_RESCHEDULE, szField, BUF_LEN); 
nIsReschedulc = TRUE; 
break; 

case MSG_RESOURCE: 

LoadString (hCardfilelnstance, 

[DS_SKWGROUP_RESOURCE_SCHEDUUE, 

szFicld, BUF_LEN); 

break; 

case MSO_DI^rRIBUTE_RESOURCE: 
LoadString (hCardfilelnstance, 

I DS_SKW0ROUP^EW_RESOURCE. 
szField, BUF_LEN); 

break; 

case MSG_RESOURCE_RESCHEDULE: 
LoadString (hCardfilelnstance, 

IDS^KWOROUP_RESOURCE_RESCHEDULE, 
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151: szFteld, BUF_LEN); 

152: break; 

153: case MSG_RESOURCE_CANCEL: 

154: LoadString (hCardRtcInstance, 

155: [DS_SKWGROUP_RESOURCE_CANCEL, 
156: szField, BUF_LEN); 

157: break; 

158: ) 

159: AppendString (IpMessage, szField, 

160: szRcturn, NULL* NULL, NULU nSizc); 

161: 

162: if (tilsReschedule) 

163: { 
164: /' 

165: if it is a reschedule operation 

166: then insert original date/time 

167: V 

168: GctGrnOimcString (IpGroup— xJwCldFromDatcTimc, 

169: IpGroup — >bTimeZone, szTime, BUF_LEN); 

170: LoadString (hCardfilelnstance, 

171 : IDS_SKWGROUP_OLD_DAre_TIME, 

172: szFicld, BUF_LEN); 

173: AppendString (Ip Message, szFicld, 

174: szSpace, szTlme, 

175: szRetum, NULL» nSize); 

176: } 

177: 

178; // Append from and to date/time 

179: LoadString (hCardfilelnstance, 

180: IDS_SKWGROUP_FROM_DATE_T[ME, 

181: szFicld, BUF_LEN); 

182: GetGmtTimeString (IpGroup — >dwFroniDateTime, 

183: lpGroup^>bTimeZone, szTime, BUF_LEN); 

184: AppendString (IpMessagc, szField, 

IgS: szSpacc, szTime, szRetum, NULL, nSize); 

186: 

187: LoadString (hCardfilelnstance, 

188: IDS_SKWGROUP_T0_DArE_TIME, szField, BUF_LEN); 

189: GctGmtTinicString (IpGroup — >dWToDate'nnic, 

190: IpGroup— >bTiineZone, szTune, BUF__LEN); 

191: AppendString (IpMessage, szFicld, 

192: szSpace, szTime, szRetum, NULL, nSize); 

193: 

194; // Append city and country information 

195: LoadString (hCardfilelnstance, 

196: IDS_SKWGROUP_CrrY, szField, BUF_LEN); 

197: AppendString (IpMessage, szField, 

198: szSpace, IpGroup — >szCity, 

199: szRcturn, NULL, nSizc); 

200: 

201: // Append location and time zone information 

202: // <Location> location nameVrVn 

203; // <'nme Zonc> time zone value\i\n 

204; // IDS_SKWGROUP_'nME_ZONE, "<Timc Zoae>" 

205: // IDS_SKWGROUP_LOCAnON, "<Location>" 

206: LoadString (hCardfilelnstance, 

207: IDS_SKWGR0UP_L0CAT10N, szField, BUF_LEN); 

208: >^)pendString (IpMessage, szField, 

209: szSpace, IpGroup — >a2Location, 

210: szRcturn, NULU nSize); 

211: LoadString (hCardfilelnstance, 

212: IDS_SKWGROUP_TIME_ZONE, szField. BUF_LEN); 

213: // nvalue « GetTlmeZone\felue (IpGroup); 

214: _itoa ((int)lpGroup— >b'nmeZone, szTune, 10); 

215: AppendString (IpMessage, szField, 

216; szSpace, szTime, szRetum, NULL, nSizc); 

217; 

218: // Append attributes 

219; // <AttributeB> "aUribute" "attribute" . . . \r\n 

220; // IDS^SKWGROUP^TTRIBUTES, "<Attributc5>'* 

221 : LoadString (hCardfilelnstance, 

222: IDS_SKWGROUP_^ATrRIBUTES, szFicld, BUF_LEN); 

223: OetAuributcStiing (IpGroup, s^TIme, BUF_LEN); 

224: AppendString (IpMessage, szField, 

225: szSpace, szTime, szRetum, NULL, nSize); 

226: 

227: // Append Event IDl 

228: // <EvcQtIDl> EventlDl value suing\r\n 

229: // IDS_SKWGROUP_EVENTID_l,-<EvenUDl>'* 

230: LoadString (hCardfilelnstance, 
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231: 
232: 
233: 
234: 
235: 
236: 
237: 
238: 
239: 
240: 
241: 
242: 
243: 
244: 
245: 
246: 
247: 
248: 
249: 
250: 
251: 
252: 
253: 
254: 
255: 
256: 
257: 
258: 
259: 
260: 
261: 
262: 
263: 
264: 
265: 
266: 
267: 
268: 
269: 
270: 
271: 
272: 
273: 
274: 
275: 
276: 
277: 
278: 
279: 
280: 
281: 
282: 
283: 
284: 
285: 
286; 
287: 
288: 
289: 
290: 
291: 
292: 
293: 
294: 
295: 
296: 
297: 
298: 
299: 
300: 
303: 
302: 
303: 
304: 
305: 
306: 
307: 
308: 
309: 
310: 



IDS_SKWGROUP_EVENnD_l, szField, BUF_LEN); 
_ltoa ((toiig)lpGioup — >dwEventID3, szUme, 30); 
AppetidString OpMessagc, szField, 

szSpace, szTiine, szRctuni, NULL, nSizc); 

// Append Event ID2 

// <EvcnaD2> EventID2 value string\r\n 

// IDS_SKWGR0UP_EVENnD_2, ''<EvcnaD2>" 

LoadStiing (hCardfilelnstance, 

IDS_SKWGR0UP_EVENnD_2. szFicld, BUF_LEN); 
_ltoa ((long) IpGroup — >dwEventID2, s^Tunc, 10); 
AppeadStiiag (IpMessage, szField, 

szSpacc, s/Hnac, 

szReturn, NUUL, nSize); 

if (IpGroup— >wFlags & EVENT_FORWARDED) 
{ 

EACH^RECIPIENrr Recipient; 



0) 



// append sender's name and sender's email address 
if (GctSender[nfo GpGroup, ARccipient, IS_SENDER) >« 
{ 

LoadString (hCardfilelnstance, 

[DS_SKWGROUP_SENDER_NAME, 
szField, BUF_LEN); 
AppcndString (IpMessage, sz;Field, 

szSpace, Recipient, szName, 
szRetum, NULL, nSize); 
LoadString (hCardfilelnstance, 

[DS_SKWGROUP_SENDER_EMAIL, 
szField, BUF_LEN); 
AppendString (IpMessage, szField, 

szSpace, Recipient, szEmail, 
szRctum, NULU nSize); 

} 

// append forward flag "1" 
LoadString (hCardilleliistance, 

IDS_SKWGROUP_IS„DELEGATE, 

szField. BUF_LEN); 
AppendString (IpMessage, szField, szSpace, 
"1", szRcturn, NULL, nsizc); 

} 

// Append Text 

// <Subject> Text body<;/Subject>\r\n 

// IDS_SKWGROUP_TEXT, "<Subiect>" 

// IDS_SKWGROUPJEND_TEXT, "</Subject>" 

if (IpGroup— >hText) 

{ 

LoadString (hCardfilelnstance, 

rDS_SKWGROUP_TEXT, 

szField, BUF_LEN); 
LoadString (hCardfilelnstance, 

IDS_SKWGROUP_END_TEXT, 

szTime, BUF_LEN); 
IpBuf - GlobalLock (IpGroup— >hText); 
AppendString (IpMessage, szField, 
szSpace, IpBuf, 
szTimc, szRcturn, nSize); 
GlobalUnlock (IpO^up — >h'Ibxt); 

} 

// Append Regarding 

// <Message Content> Regarding body -^/Message Content>\An 

// IDS_SKWGROUP_REGARDINO, "<Message Content>" 

// IDS_SKWGROUP_END_REGARDING, "<;/Message Content>" 

if (IpGroup— >hRegarding) 

{ 

LoadString (hCardfilelnstance, 

(DS_SKWGROUP_REOARDlNO, szPicld, BUF_LEN); 
LoadString (hCardfilelnstance, 

IDS_SKWGROUP_END_JlEGARDING, szTime, BUF_LEN); 
IpBuf - GlobalLocl: (IpGroup — >hRegarding); 
AppendString (IpMessage, szField, 

szSpace, IpBuf, szTlme, 

szRetuxn, nSlze); 
GlobalUnlock (IpGroup— >h Regarding); 

} 

// Append Delegate msg 

if (IpGroup— >wFlags & EVENT_FORWARDED 
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311: && IpGioup — >]pDe]egateMsg) 

312: { 

313: LoadString (hCardfilcInstancc, 

314: lDS„SKWGROUP_START_DELEGArE_MSG, 

315: szFicld, BUF_LEN); 

316: LoadString (hCardfilcInstance, 

317: IDS„SKWGROUP_END_DELEGATE_MSG, 

318: BzHmc, BUF_LEN); 

319: if (Istrlcn(lpMcssage) 

320: + Istrlcn (IpGroup — >lpDclegatcMsg) 

321: + lstrlcn(szFic]d) + Istrlcn (s^Ilmc) 

322: + 10 < nSize) 

323: AppcadString (IpMcssagc, szField, 

324: szSpace, IpGroup — >lpDelegateMsg, 

325: szUme, szReturn, nSize); 

326: } 

327: 

328: /* 

329: Append participant's name 

330: and email address to message body. 

331: •/ 

332: AppendRccipientlnfo (IpMcssage, IpGroup, 

333: nSizc, nMcssagcTypc); 
334: 

335: /* 

336: Append icsource's name 

337: and email address to message body. 

338: V 

339: if (nMessageiype !- MSG_REMINDER) 

340: AppendResourcelnfo (IpMessage, IpGroup, 

341: nSizc, nMcssagciypc); 
342: 

343: return TRUE; 



344: } 



As its first parameter, the method is passed a pointer to the ^e apjpended, respectively. In the eve nt that the messa ge 

previously-described GROUP _APPOINTMENT data i ndicaie^ttrar^e'sebedolin^ 

structure — the internal buffer storing context information Hpleg^tPfi) tQ annth er_uscr (tested at line the me thod 
characterizing a group scheduling event (including a 35 a ppepds^the sender:! s_namc and scnder ^s e-mail address, at 

message-type). At lines 29-37, local (stack) variables are linefi Additionally. an^appendT orward" fla g isset, 

declared and initialized. At lines 39-40, the method tests ki \iQ&&^266-3^, — 

whether the message-type involves a resource. For a At lines 11A^9X, the method apperids the "subject^tcxt. 

resource, the method will load a generic header for the A ny "regard ing"' message is ap^endiTd ariines*293-308, and 
message, at line 42. Otherwise (i.e., the "if* statement ^ any "delegate" message is appended at lines 310-326. To 

evaluates to "false"), the method will load into the message complete the message, the participant's name and address is 

buffer, pointed to by IpMessage, a (non-resource) message appended to the message body, at lines 329-333. Finally, 

header, provided that the mess age- type is Schedule, resource information (for any resource) is appended to the 

Reminder, Broadcast, or Reschedule. The comment set forth message body, at lines 335-341. Now, the message has been 

at lines 54-107 illustrates an exemplary message header. As successfully completed, and the method may return "true" at 
shown, the message header is formatted in a fashion which 45 line 343. Once the message has been composed, it can be 

permits a user having only basic e-mail support to read the posted to the transport layer, using the previously described 

scheduling message and reply (e.g., accept or decline) Schedul e„Group__Event Method^ 

accordingly. . , . . , j ^ • ». Receipt or the composed scheduling message by a non- 
After the rnessage header has been loaded mto the mes- § ^^^^^^ without browser support (e.g., WordPerfect Office 
sage buffer, the method proceeds to append to the message ^^^^ illustrated in BGS. 12A-C. FIG. 12A shows an 
bemg constructed the other fields set forth in the previously- ^J^^^ ^^^^^^ ^200 displaying the invitation in simple text 
described message formats. The method proceeds as fol- ^ * -I'lin auu iT *u i • i j 5 • 
lows. At Unes 110-114, the method appends the "message- ^^^^^^ j^lO. Although the message also includes ncher 
type'' dehmiter. ITiis is followed by appending the actual ^^'"^^^ H'^ Attachement(s) 1211), the remote system does 
message type for the message, at lines U6-160. SpecificaUy, recognize them and thus, can sunply ignore Ujem. As 
the method first determines the appropriate text string for the 55 shown m FIG. L2B, the remote user can reply" to the 
message type, at Unes 117-158. Then, this message string is invitation using his or her own e-mad software, as shown at 
appended to the message being constructed, at lines dialog 1220, and choose to include the message received 
159-160. from the sender, as shown at 1221. Following the instruc- 
Other fields of tbe_ message can be^ppen ded to the tions in the e-mail invitation, the remote user, as shown in 
message being created in a^simiTar' manrldr^nines FIG. 12 C, edits the reply 1211a by entering an *'X" in the [ ] 
T62-176, the method inserts the original date/time in the ^° Accept text string at 1213 and entering a brief message 
event that the message is a Reschedule _ messa ge. At lines between the <BEGIN REPLY MESSAGE> and <END 
178-192, the met hod appends th e "f rom" and 'Hp ^datcana REPLY MESSAGE> delimiters or markers 1217. 
ti me. Atjines at , iy4~T?*?* i the met hod_a ppends the ciiy a nd The above-illustrated message composition can be 
c ountry information, and_at_lines_201r216, Jie_method extended to automatically generate a Hypertext Markup 
appends location and time zone information. 65 Language (HTML) form as a scheduling invitation. Here, 
At4tae&- 218-225. attribute information is appended.. A t the HTML form is generated in a conventional manner using 
Unc&J227-234 and at 236-244, the first and second event IDs^ HTML code, except that instead of a user hand-crafting the 
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form, the system automatically maps the scheduling infor- 
mation into appropriate target destinations (fields, buttons, 
and labels) on the form. For instance, the following data 
fields are mapped to HTML fields: 



HTML field 


Mapped infonnation 


Message From: 


{Initiator} 


DaLc/ltmc: 


{Date/Time} 


Duration: 


{Duratiott} 


Time Zone: 


{Time Zone} 


Location: 


{Location} 


aty/Country: 


{City} 


Subject: 


{Subject} 


Message; 


{Message} 



Further, the "Accept" and "Decline" responses are mapped 
to HTML buttons. 

Creation of these control in HTML is straightforward. For 
instance, the "Accept" and "Decline" buttons can be emitted 
in HTML format as: 



<HTML> 

<BODY> 
<FORM> 

<Hl>Acccpt and Decline Buttons</Hl> 

<INPUT TYPE=" Accept" VALUE-"! accept the invitation"> 

<INPUT TYPE-'Decline" VALUE-*'! decline the invitation'V 
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<^ODy> 

^ORM> 
5 </HrML> 



Description of the HTML format is well documented in the 
trade literature; see e.g., Duncan, R., A« HTML Primer, PC 
10 Magazine, Jun. 13, 1995, pp. 261-270. Further desaiption 
is provided by Duncan, R., Publishing HTML Forms on the 
Web, PC Magazine, Dec. 5, 1995, pp. 391^03. The disclo- 
sures of the foregoing are hereby incorporated by reference. 

Receipt of the composed HTML scheduling message by 
15 a non-SK client with browser support (e.g., Netscape Navi- 
gator user) is illustrated in FIG. 13. The remote user employs 
the browser 1300 for displaying the invitation in hypertext 
(HTML) format 1310. The scheduling data fields are auto- 
matically placed on the fonn as HTML form fields 1311. The 
20 "Accept" and "Decline" buttons, on the other hand, are 
placed as buttons 1313. The receiving user can now simply 
respond to the form, whereupon his or her answer is trans- 
mitted back to the sender. 

d. Methodology for Parsing Messages 
^ Methods of the present invention for identifying and 
processing incoming group scheduling event messages will 
now be described. All incoming mail is initially processed 
by a ReceiveAllIncomingMaiLs method. In an exemplary 
embodiment, this method may be constructed as follows. 



2: Tliis function will receive all incoming group event messages. 

3: **• • * / 

4: int Receive Al Unco mingMails (void) 

5: { 

6: LPMESSAGEINFOSET IpEnfoSet; 

7: int i, 

S: nlists " cSchcdulcdlists^ 

9: nWantDlg-FAL5E, 

10: nResult, 

11: nPaint » FAL^E, 

12: nFoldeiCreated; 

13 : char szScndertPATHM AX+1 ], szTo[ PATHM AX+1 1 

14: szCqPATHNAX+l], szECqPATHMAX+ll 

IS : szSubjectl PATHMAX+ll szTime[ BUF_LEN+1 ], 

16: 5zEmail[65], szEraaaTypc[BUF_LEN+l], 

17: szAttach[FArHMAX+l], s2Signature[BUF_LEN+l]; 

18: HGIjOBAL hMcssage; 

19: LPSTR IpMessage; 

20: 

21: 'nirnOnnashSession ( ); 

22: IpMessage « AUocLockBuflfer (AhMessage, NOTETEXTSIZE ' 4); 

23: if (IhMessagc) 

24: { 

25: 'I\irnOfiFlashSesfiio[i { ); 

26: return FALSE; 

27: } 
28: 

29: LoadString (hCardftlelnstance, 

30: !DS_SKWGROUP_SIGNArURE, szSignature, 

31: BUF_LEN); 

32: 

33: // Get email messages from Exchange 

34: if (IsDelivcrExchange ( )) 

35: { 

36: char szFolderName[BUF_LEN+l]; 
37: 

38: // RcccivcAHNewMails (hCardfUcWnd); 

39: ReceiveAllMailsNow (hCardfileWnd); 
40: 

41: // Qeate Internet Sidekick Folder. 

42: LoadString (hC^rdfilelnstance, 
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43: [DS„[SK_FOLDER_NAME, szFolderName, BUF_LEN); 

44: nFolderCreated 

45: « CrcateAFirstLevelFoldcrloDcfaultMsgStorc 

46: { 

47: hCardfilcWnd, 

4S: szFolderName 

49: }; 

50: 

51: 

52: // Search for ISK Messages. 

53: IpInfoSct 

54: - ScarchSKWSchcduIeMsg[nInboxFolder 

55: { 

56: hCardJUeWnd, 

57: szSignature 

58: }; 

59: 

60: 

61: if (llpInfoSet) // not enough memory 

62: { 

63: UnlockFrce Buffer (hMessage); 

64: 'RirnOffFlashSession ( ); 

65: return FALSE; 

66: } 
67: 

68: if (IpInfoSct— >ulOount) 

69: { 

70: for (i-0; i<(int)lpInfoSet — >ul count; i++) 

71: { 

72: if (GetMessageContents (hCardfUeWnd, 

73: IpInfoSct— >lpMsgrnfo [iJlpEID. 

74: szSender, PATHMAX, 

75: szEmai], 64, 

76: szEmainVpe. BUF_LEN, 

77: szTo, PATHMAX, 

78: szCC. PAimiAX, 

79: szSubject, PATHMAX, 

80: IpMessage, NOTETEXTSIZE * 4, 

81: szHmc, BUF.LEN, 

82: szAttach, PATHMAX)) 

83: { 

84: 

85: trLm_6tart_end (szSender, *\", *\"); 

86: trLm_5tart_ciid (szSender, 'X"', '\"*); 

87: trim_start_end (szEmail, '\r, ' V); 

88: trim_start_end (szEmail, '\", '\"'); 

89: trim_start_cnd (s^, 'V*, *\"); 

90: trim_6tart_end (s^o, '\"*, '\"); 

91: 

92: if (!(nResuit 

93: - ReceiverMessageHandler (szSender, 

94: szEmail, szEmailiype, 

95: szTo, szCC, szSubject, 

196: ipMessage, szAttach, 

97: FALSE))) 

98: continue; 

99: 

100: nPaint = TRUE; 

101: SetMailRcad (hCardfileWnd, 

102: IpInfoSet— >lpMsgInfo[i].lpE[D); 

103: if (lIsLeavcOnServer ( )) 

104: DelctcMail (hCardfilcWnd. 

105: IpInfoSet— >lpMsgInfo [i]. IpEID, 

106: TRUE); 

107: else 

108: { 

109: if (nFoldcrCrcated) 

110: MovelSKMailsToISKMailFolder 

111: { 

112: hCardfileWnd. 

113: IpInfoSet— >lpMsgInfo[i]JpEID, 

114: szFolderNamc 

115: }; 

116: } 

117: } 

118: } 

119: } 

120: FrecMessagcInfoSet OpInfoSet); 



121: } 
122: 



06/17/2003, EAST Version: 1.03.0002 



I 



6,016,478 

49 50 

-continued 



123: // Get email messages from POP3 account, 

124: if (bDeliverOwnlnteraet ( )) 

125: { 

126: if (SFMaUGetNew (hCardfilcWnd, szSignaturc)) 

127: { 

128: if (SFMailBoiOpen ( )) 

129: { 

130: IpInfoSct » SFMailScanMail (hcardfilcWnd); 

131: if OpInfoSet) 

132: { 

133: for i<(int)lpInfoSet— >uICount; i++) 

134: { 

135: if ( SFGctMcssagcContcnts 

136: { 

137: hCardfileWnd, 

138: IpInfoSet— >lpMsgrQfo[i].!pEID, 

139: szEtnail, 64, 

140: szScndcr. PAIHMAX, 

141: //szEmailTVpe, BUF__LEN, 

142: szTo, PATHMAX, 

143: szCC, PATHMAX, 

144: szBCC, PATHMAX, 

145: szSubjcct, PATHMAX, 

146: IpMessagc, NOTETEXTSIZE * 3, 

147: BzAttach, PATHMAX, 

148: szTimc, BUF_LEN 

149: } 

150: } 

151: { 

152: 

153: triin_3tart__cnd (szScndcr, '\", '\*); 

154: tiim^tart_end (szSender, *\"', '\"*); 

155: triin_start_end (szEmail, '\", '\"); 

156: triin_start_end (szEmail, *\'*, '\"*); 

157: trim_start_end (szTo, *V', *\"); 

158: triin_^tart_cnd (szTo, '\"', '\"'); 
159: 

160: if ('(nRcsult 

161: » RcccivcrMcssagcHandlcr 

162: { 

163: szScttdtr, 

164: szEmail, 

165: ezEmailType, 

166; 8^, szCX, 

167: szSubject, IpMessage, 

168: szAttach, FALSE 

169: }}} 

170: continue; 

171: nPaint = TRUE; 

172: // delete message from inbox. 

173: if (nResult) 

174: SFDcletcMessage 

175: { 

176: hCardfileWnd, 

177: tplnfoSet— >lpMsgInfo [i].lpEID 

178: }; 

179: } 

180: } 

181: } 

182: SFMailBoxClose ( ); 

183: } 

184: } 

185: } 

186: 

187: // unlock and free message block 

188: UniockFreeBuflfer (hMcssage); 
189: 

190: 'nunOfittnashSession ( ); 

191: if(npaint) 

192: { 

193: if (hCoverPagcWnd && [sGroupPagcFront ( )) 

194: { 

195: Sort^GroupEventList (hCovcrPageWnd, NULU 

196: Get_Cunent_SortFlag ( )); 

197: ifOnUsts) 

198: { 

199: } 

200: } 

201: else 

202: SortGroupEvenanfo (hSchcdulcdUlst, cSchcduledlists, 
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203: Get„Current_SortF]ag ( )); 

204: } 

205: rctuin TRUE; 
206: } 



After initializing local (stack) variables at lines 6-19, the 
method "turns on" the "flash" session, at line 21. This sets 
a global flag for preventing re-entry, since this is a timer/ 
interrupt driven process. At lines 22-27, the method allo- 
cates a memory block for storing an incoming message. If 
the allocation fails, the method returns "false" al line 26. At 
lines 29-31, the method loads from a resource file the 
signature string (i.e., <ISK>). This string will be used to 15 
identify incoming group scheduling events. 

Now, the method is ready to retrieve e-mail messages 
from the user's in-box. At lines 35-121, the method retrieves 
messages for Microsoft Exchange and creates a folder for 
those messages (at lines 41-49). Now, the method searches 20 
in that folder for group scheduling event messages — that is, 
messages containing the identifying signature (at lines 
52-58). If at least one group scheduling event message is 
found (i.e., count is greater than zero at line 68), the method 
sets up a "for" loop at line 70, for looping through each such ^ 
message. At lines 11-^2, the message contents are extracted 
by a call to GetM ess age Con tents. At lines 85-90, any 
trailing spaces are trimmed from this extracted information. 
As shown, the extracted information includes information 
about the sender (name), e-mail (address), e-mail-type, 
"To", "CC", subject, message, time, and any attachment. 



Further processing is performed by a call to 
ReceiverMessageHandler, at line 93. The ReceiverMcssage- 
Handler method provides appropriate message handling 
(action), based on the extracted or parsed message informa- 
tion. If the message cannot be handled (i.e., the "if state- 
ment at line 92 evaluates to "false"), then the method loops 
back for the next message, by executing the "continue" 
statement at line 98. Otherwise, the message can be handled 
whereupon the method removes the message firom the user's 
in-box (lines 104-106), and places it in a group scheduling 
mail folder (lines 109-115). Thereafter, cleanup is per- 
formed at line 120. In the event that the user's e-mail system 
is from a P0P3 (Internet Post OfiHce Protocol) account, the 
method executes lines 123-185. Here, the method performs 
essentially the same task as just described for a Microsoft 
Exchange mail account. 

The method completes its operation by freeing up 
memory at lines 187-188, turning off the Sash session flag 
at line 190, and repaints the user interface with the new 
information (if needed) at lines 191-204. Thereafter, all 
incoming mail has been appropriately processed, and the 
method may return "true" at line 205. 

The message handler itself, ReceiverMessageHandler, 
may be constructed as follows. 



2: Hi is function will handle incoming group event messages. 

4: int ReceiverMessageHandler (LPSTR IpFrom, 
5: LPSTR IpEmail, 

6: LPSTR IpEmaUTVpc, 

7: LPSTR IpTo, 

8: LPSTR IpCC, 

9: LPSTR IpSubject, 

10: LPSTR IpMessage, 

11: LPSTR IpAttachFilc, 

12: int nReplyCcode) 

13: { 

14: LPSTR IpShortMsg = NULL, IpNcw » NULL; 
15: int nMsgtD 

16: = MessagcTypcParacr (IpSubjcct, IpMessagc, &lpNcw), 

17: nRepiyiype « 0; 

18: 

19: if (nMsgID == OROUP_SCHEDULE 
20: nMsgID == GROUP_BR0ADCAST 

21 : nMsgID — GROUP_RESCHEDULE) 

22: { 

23: IpShortMsg 

24: - IsThisAutoRcplyWcssagc (IpMcssagc, 

25: &DMsgID, 
26: &nRep]/IVpe>, 
27: } 
28: 

29: switch (nMsgID) 
30: { 

31 : case GROUP_REMINDER: 

32: case GROUP_SCHEDULE: 

33: case GROUP_BROADCAST 

34: return Hand]e„Schedule_>leeting 

35: { 

36: IpFrom, IpEmail, 

37: IpEmaiirypc, IpTb, 

38: IpCC, IpMessage, 

39: IpAllachFilc, nMsgID 

40: 1; 

41: 
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42: case GROUP_REPLY: 

43: return Haiidle_Reply 

44: { 

45: IpFrom, IpEmail, 

46: IpTo, IpCC, 

47: IpSubject, Ip Message, 

48: nRepl/rVpe, IpShoitMsg 

49: }; 

50: 

51: case GROUP_FREETIME: 

52: return CreateFrccnme_Matrix_Send 

53: { 

54: IpFrom, IpEmaD, 

55: IpCC, IpMessage 

56: }; 

57: 

58: case GROUP_RESCHEDULE: 

59: return Handlc_Rcschedule 

60: { 

61; IpFiom, IpEmail, 

62: IpEmainvpe, IpTb, 

63: IpCC, IpMessage, 

64: nRcplyCodc 

65: }; 

66: 

67: case GROUP_MEEnNG_N0TE: 

68: return Handle_Mecting_Notc 

69: { 

70: IpFrom, IpCC, 

71: IpMessage, IpAttachFile 

72: }; 

73: 

74: case GROUP_CANCEL_MEEnNG: 

75: return Handle_Cancel_Meetii]g (IpFrom, IpCC, IpMessage); 
76: 

77: case GROUP_JSfEW_RES0URCE: 

78: return HandJe^AddNewResouxce (IpFrom, 

79: IpEmail, IpMessage); 

80: 

81: case GROUP_JlESOURCE_SCHEDULE: 

82: case GROUP_RESOURCE_RESCHEDULE: 

83: return Handle_Resource_Schedule 

84: { 

85: IpFrom, IpEniail, 

86: IpEmailT^pc, Iplb, 

87: IpCC, IpMessage 

88: }; 

89: 

90: case GROUP_RESOURCE_CANCEL: 

91 : return Handle__Resource_Cancel (IpFrom, 

92: IpEmail, IpMessage); 

93: 

94: case GROUP_FRBE_RESOURCE: 

95: return Hand]e_Frcc_Resource (IpFrom, IpEmail, IpMessage); 
96: 

97: case GROUP_TRANSFER_RESOURCE: 

98: return HandIe_Transfer_Rcsource 

99: { 

100: IpFrom, IpEmaU, 

101: IpEmailType, IpMessage, 

102: IpAttachFile 

103: }; 

104: } 

105: return TRUE; 



106: } 



As shown, the method is invoked with parameters set 
equal to the just-extracted e-mail information. After declar- 
ing local variables at line 14, the method parses out the 
message type, at lines 15-16. At lines 19-21, the method 
examines whether the message is one which it can auto- 
matically reply to; such a condition holds true when the 
message is for a Group Schedule, Broadcast, or Reschedule. 
At lines 20-104, the method establishes a case statement 
which switches on message type or ID, for invoking more 
specialized handlers. Group Reminder, Schedule, and 
Broadcast messages, for instance, invoke a Handle_ 
Schedule ^Meeting handler at line 34. A group reply 



message, on the other hand, invokes a Handle_Jleply han- 
dler at line 43. Other handlers are invoked in a correspond- 
ing manner. A list of exemplary handlers is appended 

60 herewith as Appendix B. 

While the invention is described in some detail with 
specific reference to a single preferred embodiment and 
certain alternatives, there is no intent to limit the invention 
to that particular embodiment or those specific alternatives. 

65 Thus, the true scope of the present invention is not limited 
to any one of the foregoing exemplary embodiments but is 
instead defined by the appended claims. 
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APPENDIX A 

Exemplary Message Formats 

Group scheduling format design 

1. Internet appointment message format 

Bvcry type of message will have following two parts at least 

<Product Signature> := <ISK>(or <SIS>) 

<Message Type> :- <Schedule | Broadcast | Reply | Free Hme | Reminder | 
Reschedule | Meeting Note | Cancel | Recuning | New Resource | Resource | Action | 
Synchron Lzation > 
Schedule and Broadcast: 



<From Date 'nme> 
<flb Date 'nme> 
<Location> 
<City> 
<^rimc Zoiie> 
<Attributes> 
<EventIDl> 
<EventID2> 
<Subject> 
<Me5sage Content> 
<ParticipaQts> 



:- YY/MM/DD HH:MM 
:= YY/MM/DD HH:MM 
Place name where the meeting will be held. 

City name where the meeting will be held It is related to Time Zone, 
^me zone name where appointment time is based on> 
<Alarm> 

A unique ID for the event 
The second part of the tD. 
<Message text><ySubject> 
:■ <Regarding textx/Mcssage Content> 
:- "Name; Email address; Email Type" "Name; Email Address; 
Email Type" </Participants> 

<CC> :» "Name; Email address; Email Type" "Name; Email Address; Email Type" 
<JCC> 

<Room>:= "Name; Email address; Email Type" "Name; Email Address; Email T^pe" 
<:/Room> 

<Equipmcnt>> "Name; Email address; Email Type" **Name; Email Address; Email T^pc" 
</Equipment> 

If this message is a broadcast message, it requires no ACCEPT response. 
Rq)ly: 

<Reply Types> :- <Accept | Decline | Reschedule Required | Sleep | Forward | 

Resource | Free Time? 

<ForwardTo> <Name; E-mail address; Email Type><;/Forward To> 

« [f Reschedule required 

<From Date rune> :- YY/MM/DD HH:MM 
<To Date Timo YY/MM/DD HH:MM 

» 

<Event[Dl> ;» A unique ID for the event 

<EventID2> The second part of the ID. 

<Short Message> := <Short text message></Short Message> 

«If it is a Reschedule Required, Free Time Request, or Resource Reservation type of 

Schedule 

There is a file attached on this message 

The Reschedule Required type of reply is for the purpose of rescheduling right away. For 

example, a person received a group meeting request He does not have free time. So he 

requires to reschedule the meeting with different time. 

The purpose of Sleep type is for people on vacation or leaving. 

Free Time: (A Free Time request message) 

<EventIDl> A unique ID for this Free Time request 

<EventID2> :- The second part of the ID. 

<:From Date Tuno :- YY/MM/DD HH:MM 

<rro Date rune> YY/MM/DD HH:MM 

<Subject> <Message text></Subject> 

This is an auto reply message request The reply result of Free Time report is a text matrix 

with 0 and 1. 

Reschedule: 



<0]d Date/nme> :- YY/MM/DD; HH:MM. 

<From Dale Tlmo := YY/MM/DD HH:MM 

<flb Date Time> := YY/MM/DD HH:MM 

<Location> :- Place tx&mc where the meeting wiil be held, 

<City> :- City name where the meeting wiil be held. It is related to Time Zone. 

•^Hme Zone> :- <Time zone name where appointment time is based on> 

<Attribute5> :■ <Alarm | Previously Status: Accept; Dcclino 

<EventIDl> A unique ID for the event 

<EventID2> TTie second part of the ID. 

<Subject> := <Messagc tcxt></Subject> 

<Message Content> <Regarding text></Subject> 

<Participants> :- "Name; Email address; Email TVpe" "Name; Email Address; 
Email Typt" </Pariicipants> 

<CC>:- "Name; Email address; Email Type" "Name; Email Address; Email Type" 

<ycc> 

<Room> :- "Name; Email address; Email TVF*" "Name; Email Address; Email 

TVpe"^;/ 

</Room> 
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APPENDIX A-continued 



Exemplary Message Fonnats 



<Equipmeiit> "Name; Email address; Email Type" "Name; Email Address; Email 

•<^quipment> 

If this meeting Ls prcvioxisly accepted, then a forced change appointment list will happen. If 
this meeting is previously declined or not responded, then it is handled like a normal schedule 
request 

A Resource request message will be sent again when a Reschedule message is sent. 
Reminder: 



<From Date Hmo 
-^o Date Time> 
<Lx)cation> := 
<City> := 
<Timc Zonc> > 
<Attributes> := 
<EvenaDl> > 
<EvcntID2> :» 
<:Subject> 

<Message Content> 
#if not Broadcast 
<Participants> 

Email Type" </Participant5> 

<cx:>:= 

<;/CC> 



:= YY/MM/DD HH:MM 
:- YY/MM/DD HH:MM 
Place name where the meeting will be held. 

City name where the meeting will be held. It is related to Time Zone. 
<'Iime zone name where appointment time is based on> 
<Alarm ll Previous Status: Accept; Declino 
A unique ID for the event. 
Ttie second part of the ID. 
<Message text><ySubject> 

<Regarding text> ^Message Content> 



> "Name; Email address; Email Type" "Name; Email Address; 
at5> 

"Name; Email address; Email Type" "Name; Email Address; Email Type" 
"Name; Email address; Email Type" "Name; Email Address; Email 



"Name; Email address; Email Type" "Nana; Email Address; Email 



<Room> 
lype" </ 
<yRoom> 
<Equipinent> :« 
Type" </ 
<y'Equipment> 

[f this meeting is previously accepted, the ACCEPT button will be grayed out. If this meeting 
is not responded, it is handled like a normal schedule. 
Meeting Note: 



<Froni Date Time> 
-efTo Date Time> 
<Location> 
<City> := 
<frimc Zone> := 
<EvcntIDl> := 
<EventID2> > 
<Subject> > 
<Meeting Notc> 



:= YY/MM/DD HH:MM 
:= YY/MM/DD HH:MM 
Place name where the meeting was held. 

City name where the meeting will be held. It is related to Time Zone. 

<Time zone name where appointment time is based on> 

A unique ID for the event 

The second part of the [D. 

<Message text>-</Subject> 

;= The meeting note tcxt-^/Meeting Notc> 



Cancel a group meeting: 

<Event[Dl> A unique ID for the event 

<EventID2> :- The second part of the ID. 
<Subject> cMcssagc tcxt></Subject> 

<5hort Mes5age> :« <Message textx/Short Messago 
Resource: (Resource Reservation Message) 



<From Date TIme> 
<fro Date Time> 
<EventIDl> := 
<EventiD2> :- 
<Subject> := 
<Message Content> 
Schedule a recurring Appointment: 



YY/MM/DD HH:MM 
;= YY/MM/DD HH:MM 
A unique ID for the event 
The second part of the ID 
<Message tcxt></Subjcct> 

<Regarding textx;/ Message Content> 



<Start Date> 
<End Datc> :- 
<From Date Tlme> 
<To Date T\me> 
<Rccur Pattern 1> 
<Recur Pattern 2> 
<Recur Pattern 3> 
<Location> :> 
<City> :- 
<nme Zone> :- 
<Attributes> :« 
<Subjcct> :- 
<Message Content> 



YY/MM/DD 
YY/MM/DD 

YY/MM/DD HH:MM 
YY/MM/DD HH:MM 
Month I Week | Day 
Frequency 

Include and Exclude 
Place name where the meeting will be held. 

City name where the meeting will be held. It is related to Time Zone. 

<fltme zone name where appointment time is based on> 

<Alarm> 

cMcssage tcxt><ySubject> 

<Regarding textx/Message Content> 



Executing an Action cross the serverless oetwork: 



<From Date Tlme> 

Date Time> 
<Location> 



:- YY/MM/DD HH:MM 
:- YY/MM/DD HH:MM 
Place name where the meeting will be held. 
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APPENDIX A-continued 



Exemplary Message Fonnats 



<aty> :- 
<fnme Zone> :» 
<EventIDl> :- 
<EvcntID2> := 
<Subject> := 
<Message Content> 
<Action Itcm> 
recognized in Sidekick> 
Synchronizing files cross the network: 



City name where the meeting will be held It is related to Time Zone, 
■dime zone name where appointment lime is based on> 
A unique ID for the evenL 
The second part of the ID. 
<Message ieit></Suhject> 
:- <Regarding textx^Message Content> 
> <Java applet | An executable program | operations which can be 



<From Date Tlm6> 
<CVo Date Tirno 
<Location> 
<City> :» 
-tfrLme Zone> > 
<EventIDl> := 
<EventID2> :- 
<Subject> := 
<Me5sag6 Contcnt> 



:- YY/MM/DD HH:MM 
YY/MM/DD HH:MM 
Place name where the meeting will be held 

City name where the meeting will be held It is related to Tune Zone. 
<Tlme zone name where appointment time is based on> 
A unique ID for the event 
The second part of the ID. 
<Message teit></Subject> 
:= <Rcgarding textx^Mcssagc Content> 
<File Name>:= <File name which needs to be synchronized> 

Resource scheduling requires non-overlapped time and a subject The scheduling is a 
non-negotiable process. The reply only has two options: Accept and Decline. 



APPENfDIX B 



Exemplary Message Handlers for Actions 

int Handle_Schedu]e_Meetiiig (LPSTR lpFrom» 

LPST^ IpEmail, 
LPSTE IpEmailTVpe, 
1J»STR IpTo, 
LPSTO IpCC, 
LPSTO IpMessage, 
LPSTR IpAttachFile, 
int nMsgID) 

// This function will scan the incoming message and get all the 
// information related to this event. 



// Information includes following parts: 

// - start date/ time and end date/time 

// - time zone 

/y - location 

// - City and country 

// - Event properties, such as alarm, tentative, RSVP, etc.. 

// - Participants info 

// - Resource allocated for this event 

y/ - Event ID 

// - Subject 

// - Message body 



// After getting the information, it will add one item into Event List 
// database 

// Tlis function will also handle the Reminder and Confirm message type 

// 

return TRUE; 

} 

..«««..,,,,.,**.«...«.«...«..*...« 

int Handle_Reschcdule (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpEmailType, LPSTR 
Iplb, LPSTR IpCC, LPSTR IpMessage, int nReplyCode) 

// This function will scan incoming message ai«i get all the information 
// It will set new value to the same item in the Event database 

} 

/ * « 

• 

int Handle_Jleply (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpTb, LPSTR IpCC, LPSTR 
IpSubject, LPSTR IpMessage, int nInReplyTypc, LPSFR IpShorlMsg) 

1. Get group schedule information inchidcd in IpMessage; 

2. Get Reply type information included in IpMessage; 

3. Handle Group Meeting update, including change recipient status, 
change recipient if it is a forward to type of reply. 
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APPENDIX B-continued 



Exemplary Message Handleis for Actioos 



} 

int CrcatcFrccTimc_Matrix_Scnd (LFSTR IpFrom, LPSTR IpEmail. LPSTR IpCC, LPSTR 

Ip Message) 

{ 

// Create a free time caleadar and send to initiator 

} 

• ' 

int Handle_>leetin&__Note (LPSTTR IpFrom, LPSTR tpCC, LPSTR IpMessagc, LPSTR 

IpAttachFiic) 

{ 

/y get minutes of meeting and attached file and 
// save to the Event 

} 

* • 



int Elandle Canccl_J»Ieeting (LPSTR IpFrom, LPSTR IpCC, LPSTR IpMessage) 
{ 

// get information from message 

// delete event from calendar 

// set cunent event to canceled status 

} 

/ • * 



int Handle_Rc50urce_Schcdule (LPSTR IpFrom, LPSTR IpEmail, LFSTR IpEmailTVpe, 
LPSTR IpTo, LFSTR IpCC, LPSTR IpMessage) 

{ 

// get information from message 

// try to reserve the resource 

// send reply back to initiatoi (accept or decline) 

} 

^« 44 4*4«*««**ilii«it*ilt ********* 

.4«4«.......«.«*.*44444.4..4..44.......««.«»..«4.44.44. 4 4 4 4/ 

{ 

mt HandIe_Re8ource_Cancel (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpMessage) 
// cancel resource reservation 

} 

^..........„....44444444 4 « . 4 . 4 . 4 . 4 4 4 4 4 4 . . . 4 4 4 4 4 4 .....444.44.4.4.4*4 

* * * 44.444/ 

int Handlc_Frcc_Rcsource (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpMessage) 
// create resource ficc time calendar and send to intiator 

} 

/«..«44«.»...»44..«44444*44444*«*4**** 4 4 4 4 4 4 ******* 4 4 4 4 4 .4 4 4 4 4 4 4 .» 4 4 . 4 * 4 ** * 

- 4444,44.. .4 44/ 

int Handle_Transfer_Resource (LPSTR IpFrom, LPSTR IpEmail, LPSTR IpEmailiype, 

LPSTR IpMessage, LPSTR IpAttachFiic) 

{ 

// get transfer resource and add an item to event database 

} 



What is claimed is: 50 
1. In a computerized scheduling system, a method for 

assisting a user with scheduling calendar events in an 

electronic calendar, the method comprismg: 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to 55 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 60 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 

a plurality of different message formats, each message 
format supporting a different level of information 
content, said plurality of different message formats 65 
selected from a group comprising at least a proprietary 
scheduling format, a Hypertext Markup Language 



(HTML) format, and a simple electronic-mail format so 
that said scheduling invitation may be encoded for 
appropriate processing by disparate remote computer 
systems including those which are unable to interpret 
proprietary scheduling formats of the computerized 
scheduling system of the user; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduhng reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said eadi participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 
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(e) upoD receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply. 

2. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising; 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 
scheduhng invitation which invites the participants to 
the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant. 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said user; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein at least one message format comprises a pro- 35 
prictary scheduling format of the computerized sched- 
uling system of the user. 

3. The method of claim 2, wherein said message format 
which comprises a proprietary scheduling format of the 
computerized scheduling system of the user is transmitted in 40 
the electronic scheduling message as a binary attachment. 

4. The method of claim 3, wherein said binary attachment 
comprises a Muhipurpose-Internet-Mail-Extensions binary 
attachment. 

5. The method of claim 1, wherein at least one message 
format comprises a simple text message ensuring that a 
participant employing a computer system providing only 
simple electronic-mail support can reply to said electronic 
scheduling message. 

6. The method of claim 1, wherein said input received 
from the user comprises an event time and location. 

7. The method of claim 6, wherein at least one of the 
scheduling replies comprises a reply indicating that a par- 
ticipant cannot participate in the event and further includes 
information indicating an alternate time for scheduling the 55 
event. 

8. In a computerized scheduling system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising: 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
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the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
formal supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduling invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduling reply to said iiser; and 

(e) upon receiving each participant's scheduling reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein said message format which comprises a 
Hypertext Markup Language (HTML) form automati- 
cally generated by the system based on said input from 
the user, said HTML form capable of being viewed by 
any participant having an HTML browser. 

9. The method of claim 8, wherein said HTML form 
comprises form fields displaying said input from the user, 
and further comprises screen buttons which a participant can 
select for generating a reply. 

10. In a computerized scheduhng system, a method for 
assisting a user with scheduling calendar events in an 
electronic calendar, the method comprising: 

(a) receiving input from the user specifying an event to 
schedule together with a lists of participants desired to 
participate in the event, at least some of said partici- 
pants employing remote computer systems which are 
unable to interpret proprietary scheduling formats of 
the computerized scheduling system of the user; 

(b) in response to said input, generating an electronic 
scheduling invitation which invites the participants to 
the event, said scheduling invitation being encoded in 
a plurality of different message formats, each message 
format supporting a different level of information con- 
tent; 

(c) sending said scheduling invitation to each participant; 

(d) upon receiving said scheduhng invitation, generating 
an electronic scheduling reply by: 

(i) decoding the message format having the highest 
level of information content suitable for the com- 
puter system employed by said each participant, 

(ii) creating an electronic scheduling reply suitable for 
automatic processing by said computerized schedul- 
ing system of the user, said reply including a 
response indicating whether said each participant 
can participate in the event, and 

(iii) sending said scheduhng reply to said user; and 

(e) upon receiving each participant's scheduhng reply, 
automatically updating the calendar based on the 
response contained within the scheduling reply, 
wherein said a different level of information content 
comprises selected ones of a proprietary scheduling 
format of the computerized scheduling system, a 
Hypertext Markup Language (HTML) format, and a 
simple text format. 

11. The method of claim 1, wherein said electronic 
scheduling invitation includes an embedded identifier which 
is incorporated into each reply so that said computerized 



06/17/2003, EAST Version: 1.03.0002 



6,016,478 



65 



66 



scheduling system caa automatically differentiate the replies 
from other electronic mail which the user receives. 

12. The method of claim 11, wherein said embedded 
identifier includes information allowing said computerized 
scheduling system to automatically identify the replies as 
being associated with a particular electronic scheduling 
invitation. 

13. The method of claim 1, wherein each reply includes 
a participant identifier allowing said computerized schedul- 
ing system to automatically associate each reply with a 
particular participant. 

14. The method of claim 13, wherein step (e) includes 
indicating in the calendar which participants can attend. 

15. The method of claim 1, wherein step (c) includes: 
transmitting said scheduling invitation via a particular 

electronic-mail format of America On-line, 
CompuServe, Microsoft Exchange, and Internet P0P3, 
wherein the particular electronic-mail format employed 
is selected based on an electronic-mail address for each 
participant. 

16. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 

a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes schedtiling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system, said plurality formats 
selected from a group comprising at least a proprietary 
scheduling format, a Hypertext Markup Language 
(HTML) format, and a simple electronic-mail format so 
that said e-mail invitation may be encoded for appro- 
priate processing by disparate e-mail systems including 
those which are unable to interpret proprietary sched- 
uling formats of said automated electronic scheduling 
system; 

an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 

means for identifying each reply which responds to the 
e-mail invitation; and 

a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event. 

17. The system of claim 16, further comprising: 

a calendar update module for automatically indicating 
which desired participants can attend the particular 
event. 

18. The system of claim 16, wherein said composer inserts 
an identifier into ihc e-mail invitation so that any reply 
which incorporates contents of the e-mail invitation can be 
associated with the particular event. 

19. The system of claim 18, wherein said identifier is 
inserted into a subject line of the e-mail invitation. 

20. The system of claim 16, wherein said composer inserts 
into the e-mail invitation for each particular desired partici- 
pant an identifier for the participant so that any reply which 
incorporates contents of the e-mail invitation can be asso- 
ciated with the particular desired participant. 

21. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 
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a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (e-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
5 supporting e-mail systems other than said automated 
electronic scheduling system; 
an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 
10 means for identifying each reply which responds to the 
e-mail invitation; and 
a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event, 
15 wherein said formats comprise at least a simple text 
message imderstood by any participant having a system 
with simple e-mail support, a Hypertext Markup Lan- 
guage (HTML) form understood by any participant 
having a system with an Internet browser, and a binary 
attachment understood by any participant having the 
automated electronic scheduling system. 

22. The system of claim 21, wherein said simple text 
message includes delimiters for recording a desired partici- 
pant's response in a manner which can be identified by the 
parser. 

23. The system of claim 22, wherein said delimiters 
comprise text strings having a form substantially like [ ] 
Accept and [ ] Decline, for allowing a desired participant to 
indicate whether the participant can attend the particular 

30 event. 

24 . The system of claim 22, wherein said delimiters fur- 
ther comprise text strings having a form substantially like 
<BEGIN REPLY MESSAGE> and <END REPLY 
MESSAGE>, for allowing a desired participant to enter a 
reply which is automatically recognized and processed by 
the system. 

25. An automated electronic scheduling system compris- 
ing: 

a computer having a processor and a memory; 
a user interface for inputting a particular event for sched- 
uling; 

a composer, responsive to said user interface, for auto- 
matically generating an electronic mail (c-mail) invi- 
tation which encodes scheduling information in for- 
mats of differing levels of information content for 
supporting e-mail systems other than said automated 
electronic scheduling system; 
an e-mail transport mechanism for sending the e-mail 
invitation to each desired participants, at least some of 
who reply to the e-mail invitation; and 
means for identifying each reply which responds to the 

e-mail invitation; and 
a parser, responsive to identification means, for extracting 
from each reply information indicating whether a 
desired participant can attend the particular event, 
wherein said e-mail transport mechanism is a selected 
one of a Microsoft MAPI (Messaging Application 
Programming Interface) compliant e-mail transport 
60 mechanism and a P0P3 (Internet Post Office Protocol) 
compliant e-mail transport mechanism. 

26. A method for unattended scheduling of resources, the 
method comprising: 

storing in a computer information describing a set of 
65 resources which are available for use by individuals; 
providing at least one electronic mail (e-mail) account at 
the computer for receiving e-mail scheduling requests 
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from the individuals for scheduling use of the resources 30. The method of claim 29, wherein said movable type 

at particular times; of resource includes an "equipment" resource type. 

for such an e -mail request received at the computer. 31. The method of claim 29, wherein said immovable type 
processing the e-mail request for identirymg a partial- _ • , j u »» 

lar individual who is requesting a particular resource at , of resource mcludes a "room resource type, 
a requested time; 32. The method of claim 31, wherein said scheduling 

comparing the received request against a scheduling cal- calendar also maintains schedules for meetings of the indi- 

endar listing availability of the particular resource at viduals and wherein individuals are not allowed to schedule 
the requested time; and meetings which require an identical resource which is of 

if the particular resource is available at the requested time, ^ "room " 

automatically sending a reply e-mail message to the ^ * . r , • . • u- u - 

particular individual confinning acceptanct of the ^3. The method of clami 29, wherein a resource which is 

scheduling request and updating the scheduling calen- immovable is not allowed to accept scheduhng requests 

dar for indicating that the particular resource is now specifying times which overlap. 

scheduled at the requested time for use by the particular 34^ xhe method of claim 29, wherein a resource which is 

individual. . . . movable is allowed to accept scheduling requests specifying 

27. nie method of claim 26, further compmrng: ^^^^ ^^^^^ ^ 

if the particular resource is unavailable at the requested ,.,.,->*^t i 

time, automatically sending a reply e-mail message to ^5. The method of claim 26. wherein said processmg the 

the particular individual denying acceptance of the e-mail request includes parsing the e-mail request to extract 
scheduling request. 20 an identifier indicating that the e-mail is a scheduling request 

28. The method of claim 27, wherein said reply e-mail for ^ resource. 

message further comprises a report indicating availability of 3^ ^^^j^^^ ^^^^ 26, wherein said requested time 

the particular resource for a given time period. . ^ ^. „ j 1. *i. * , *• 

29. The method of claim 26, wherein said set of resources ^ automatically converted by the system to a time zone 
include at least two types of resources selected from a 25 relative to where the particular individual resides, 
movable type of resource and an immovable type of 

resource. ***** 
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ABSTRACT 



A graphical user interface for a computer program include s 
iKe representation of a face (an avatar) on a computer scree n 
whiclLallows a user to communicate the user's attitude to a 
s ituation rep re sented by the computer program. Th e expres - 
sion of the_faoe-cbaj:ige^acci:)rdin ) ; to the user ^s movement 
o f a cursor over the face. In response to a situation a p pigari ng 
on the computer screen, th e user sets the exp ress ion on th e 
face to correspond. witiTthc user's attitude. Th e situation on 
tfi F computer screen changes accordingly . 

20 Claims, 4 Drawing Sheets 
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GRAPHICAL USER INTERFACE TO 
COMMUNICATE ATTITUDE OR EMOTION 
TO A COMPUTER PROGRAM 

HELD OF THE INVENTION 

The invention relates to graphical user interfaces and is 
particularly concerned with graphical user interfaces in 
computer programs. 

BACKGROUND OF THE INVENTION 

Pictorial-based interfaces in computer programs are well- 
known. For example, U.S. Pat. No. 4,752,069 issued to 
Okada in 1988 allows a video game user to change the 
movement of a character on the video screen by shifting a 
lever in the desired direction. An arrow on the computer 
screen indicates the direction in which the lever ought to be 
shifted in order to effect successful movement of the char- 
acter on the screen. Since the arrow simply tells the user how 
to behave in order to succeed in the game, the game does not 
require any independent thought on the part of the user. 

U.S. Pat. No. 5,452,414 issued to Rosendahl in 1995 
relates to a raanipulable icon. Icons are typically two dimen- 
sional and display information about aspects of a computer 
program. The icon disclosed in this patent is notionally three 
dimensional and can be manipulated to show different 
information about an application such as the name of a 
document, its size, its creator, copyright information, etc. 
The icon described in this patent acts as a vehicle to transmit 
information about one or many documents to the user. The 
icon does not otherwise help the user interact with a par- 
ticular computer application. In other words, while the icon 
provides information to the user, it does not help the user 
communicate information to a computer application. 

U,S. Pat. No. 5,498,002 issued to Gechtcr in 1996 
describes an interactive, electronic game having, among 
other aspects, "character behaviour controllers". The patent 
describes a game in which a user can choose a character and 
then control its behaviour according to the character's 
"character controller logic". For example, when a character 
is selected, a pop -up window may appear allowing the user 
to modify the character's actions or behaviour by selecting 
desired options from the pop-up menu. In other words, the 
user controls the character's behaviour directly by inputting 
specific commands. The characters simply behave as 
instructed by the user. The characters do not react to the 
user's behaviour or attitude to a particular situation. 

There is at least one game available in which the char- 
acters behave according to or in response to a user's mood. 
In other words, the user does not tell the characters how to 
behave. Rather, in the game "Mode", produced by the 
company Animatics and available on the World Wide Web 
on the Internet, the user indicates his or her mood to a 
particular situation in the game, and the characters in the 
game react accordingly. The user indicates his or her mood 
by moving the cursor on the "Mood Bar" depicted on the 
computer screen and clicking the mouse. The Mood Bar is 
a rectangle showing a spectrum of colours, with red on the 
left hand side and green on the right hand side with appro- 
priately varying colours in the middle. The user is meant to 
indicate his or her mood to a particular character or situation 
in the game by moving the cursor on the colour that best 
represents the user's mood (red for angry and green for 
happy, for example) and clicking the mouse. The characters 
in the game will then react appropriately in view of the 
user's mood. 

While the Mood Bar docs allow the game's characters to 
behave or react in response to the user's mood, the game 
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does not consider other aspects of the user's personality or 
emotions. For example, a user could be in a good mood 
despite negative events that might occur in the game. 
Accordingly, it would be desirable to allow the characters in 

5 a computer game or program to react to aspects of the user's 
attitude to a situation in the game or program which could 
change from event to event, even though the user's mood 
may remain the same. Further, to reflect real-life situations, 
it may be more helpful or educational to the user to be able 

10 to see how his or her attitude may affect a given character's 
behaviour in a particular situation. 

As indicated above, with the Mood Bar, the user points 
the cursor at a colour that represents his or her mood and 
clicks the mouse. However, the Mood Bar fails to provide 

15 any indication to the user as to the mood just selected or any 
indication that the program has even registered (or taken into 
consideration) the newly selected mood. 

SUMMARY OF THE INVENTION 

^ It is an object of the invention is to obviate or mitigate one 
or more of the above identified disadvantages. 

According to a first broad aspect, the invention provides 
a computer program for use in a computer apparatus, the 

^ computer apparatus having a visual display device, an audio 
device and an input means, wherein the computer program 
when implemented on the computer apparatus displays on 
the display device a graphical user interface having a 
changeable appearance and wherein, in response to infor- 
mation conveyed by the computer program on at least one of 
the display device and the audio device, a user, using the 
input means, sets the appearance of the graphical user 
interface to correspond with an emotion of the iiser and 
wherein in response to the emotion of the user as represented 
on the graphical user interface, the computer program con- 
veys further information on at least one of the display device 
and the audio device. 

According to another broad aspect, the invention provides 
an interactive, electronic apparatus for a user to communi- 

4Q cate the emotion of the user comprising a display screen; an 
audio device; a graphical user interface visible on the 
display screen and having a changeable appearance; an input 
device for the user to set the appearance of the graphical user 
interface to correspond with an emotion of the user, a 

45 computer program implemented on the interactive, elec- 
tronic apparatus, for conveying information on at least one 
of the display screen and the audio device and wherein in 
response to the emotion of the \iser as represented in the 
appearance of the graphical user interface, the computer 

50 program conveys further information on at least one of the 
display screen and the audio device. 

According to yet another broad aspect, the invention 
provides a method for a user to interact with a computer 
program run on a computer wherein the computer comprises 

55 a display means, an audio device and an input means and the 
computer program displays a graphical user interface having 
a changeable appearance on the display means, wherein the 
method comprises the steps of the computer program con- 
veying information on at least one of the display means and 

60 the audio device; the user, using the input means, setting the 
appearance of the graphical user interface to correspond 
with an emotion of the user; and the computer program 
conveying further information on at least one of the display 
means and the audio device in response to the emotion of the 

65 user as represented on the graphical user interface. I 
Advantages of the present invention include allowing a 
user to interact with characters of a computer program by 
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having the us^ r exp ress hi s nr her atti tude to particular 
c tiaracters or situations produced bv_tbe_prosram and havi afi 
t he characters or situation in the program change acco rd- 
. iagly. It is another advantage of the present ipveation to 
provi de the user with imme diate feedback showing a rep- 
re sentation ot th e user's attitude. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the invention will now be 
described with reference to the attached drawings in which 

FIGS, la and b are representations of a computer screen 
having a graphical user interface depicting a positive and 
negative attitude, respectively, in accordance with an 
embodiment of the present invention; 

FIGS. 2a and 2b are state diagrams of graphical user 
interfaces in accordance with an embodiment of the present 
invention when the graphical user interface has only three 
states and only five states, respectively. 

FIG. 3 is a flow chart depicting the process steps carried 20 
out by the preferred embodiment of the present invention; 

FIG. 4 is a decision tree illustrating possible decisions at 
various times during progress of a computer program in 
accordance with an embodiment of the present invention 
where the graphical user interface has three states as shown ^ 
in nc. 2a. 
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DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

T he present invention relates to a graphical user interfa ce 
f dTtnteractive computer software pro grams. Auser maiii pu- 
lates the graphi cal user interface to reflect the user's attitud e 
or other emotion . In view oi a user's atuiuae or oth er 
"e^^^^^ r epresented by the graphical user interfa ce, 35 
c haracters m tne program react accordingly. Computer pr o- 
grams used in accordance with the preferred e mbodiment of 
tfa^ p resent inveniion are interactive and couig'bT^m es, 
g gvemmental or corporate employee train ing software or 
personnel assessment software, tor exam ple, of course, ^ 
I nasmuch as software can be incorporate d in or~ars"part of 
co mputer hardware, the invention could aIsoT?e oTform part 
of computer hardware. That said, the preferred em bodiment 
o f the present inveution relates to software, as"descril5e d 
b&\M^ 45 

The computer has a microprocessor which controls the 
processes referred to below including the display on the 
computer screen. 

FIGS, la and lb are representations of a computer display 
10 having a graphical user interface ("GUP') 16 comprising so 
an avatar 17. An avatar is a representation of the user of the 
computer program. In other words, the avatar is dynamic 
and represents certain changeable attributes of the user. The 
avatar 17 of FIG. la represents a user with a positive 
attitude, for example, while the avatar 17 of FIG. lb 55 
represents a user with a negative attitude. The smiling face 
shown in the avatar of FIG. la is merely a depiction of a 
person with a positive attitude. Of course, it is possible for 
a person to have a negative attitude and smile at the same 
time and, accordingly, more accurate or different represen- 60 
tations of the user's attitude are, of course, possible. For 
example, the avatar could be an entire body of a person 
instead of just the face and the user's attitude could be 
depicted by the body language of the avatar or by the 
expression on the face of the avatar in addition to body 65 
language of the avatar. For example, an avatar with slouched 
posture or crossed legs could, for example, depict a negative 



attitude, while upright posture and open legs may depict a 
positive attitude. 

The GUI 16 occupies an area of the computer display 10. 
The representation of the GUI 16 on the computer display 16 
could consist entirely of an avatar 17, for example, or as 
shown in FIGS, la or lb, the GUI 16 could additionally 
occupy an area around avatar 17, which in FIGS, la and (b) 
are rectangles. The area of the GUI 16 around the avatar 17 
could, however, be of any shape and size. 

The computer display 10 also has an area 12 showing a 
computer program's character(s) 14 in various situations. 
The GUI 16 is manipulated by the user so as to reflect the 
user's attitude (or other emotion) to the character 14 or 
situation currently displayed in area 12. The avatar 17 of the 
GUI 16 in FIG. la reflects the user's positive attitude, 
whereas the avatar 17 of GUI 16 in FIG. lb reflects the 
user's negative attitude. 

According to the preferred embodiment of the present 
invention, the user indicates his or her attitude to a situation 
by first using a computer mouse (not shown) to move a 
cursor 20 over the GUI 16. When the cursor is outside the 
GUI 16, the cursor 20 appears in a default form, which, as 
shown in FIG. la, is in the form of a single-headed anow, 
although, -of course, any other shape for the default cursor 
can be used. When the user moves the cursor 20 over the 
GUI 16, the shape of the cursor changes its form, which in 
the embodiment shown in FIG. lb, is a double-headed 
arrow, to indicate that the user can now input his or her 
attitude. When the cursor 20 is moved or placed over the 
GUI 16, the user can then input his or her altitude to the 
current situation or character by clicking a button of the 
mouse and holding the button down while moving the cursor 
20 either right or left. If the cursor is moved right, the 
expression on the avatar 17 of the GUI 16 will change to 
become more positive. If the cursor is moved to the left, the 
expression on the avatar 17 of the GUI 16 will change to 
become more negative. When the user unclicks the mouse, 
the current expression of the avatar 17 of the GUI 16 reflects 
the user's attitude to the current situation in the computer 
program, and the character(s) 14 in area 12 will react 
accordingly. 

Of course, instead of the user manipulating a mouse, 
movement of the cursor could also be effected by any of a 
number of possible input or pointing means such as by 
pressing appropriately programmed key sequences of a 
computer keyboard or by using a joystick, track ball or touch 
pad, for example. Alternatively, a cursor may not be neces- 
sary at all, where certain keystrokes or a joystick or verbal 
commands, for example, are programmed to control the GUI 
16 directly. 

The GUI 16 could be programmed to have or represent 
any number of different possible attitudes. FIG. 2a is a slate 
diagram of an embodiment of the present invention where 
the GUI 16 has a total of three different attitudes, namely 
negative 22, neutral 24 and positive 26. For example, if the 
GUI 16 currently reflects a neutral attitude 24 and the user 
places the cursor 20 over the GUI 16 and clicks the mouse 
and moves the cursor 20 left, then the GUI 16 will become 
negative 22. In other words, the expression on the avatar in 
GUI 16 will change to reflect a negative attitude. If the 
cursor 20 is now moved to the right, the avatar in GUI 16 
will change to reflect a neutral attitude 24. If the cursor is 
moved further to the right, the expression on the avatar will 
change to reflect a positive attitude 26. The GUI could be 
programmed to reflect any number of different possible 
attitudes. FIG. 2b for example, is a state diagram of an 
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embodiment of the present invention where the GUI 16 has 
been programmed to have five possible different attitudes 
(ie: more negative, negative, neutral, positive, more 
positive). 

Referring to FIG. 3, a flow chart is shown depicting the 5 
process steps carried out by the preferred embodiment of the 
present invention. When the computer program begins, it 
will likely present an initial situation or present a character 
14 to the user on an output device, likely either visually on 
the display 10 or possibly aurally, through a speaker (not 10 
shown). As shown at "start" block 40, the GUI 16 will likely 
initially be set to reflect a neutral attitude and the cursor 20 
will have a default appearance. The microprocessor will then 
consider whether or not the user has moved the cursor 20 
over the GUI 16 as shown at block 42. If the cursor 20 is not 15 
over the GUI 16, then the cursor 20 will maintain its default 
appearance as shown at block 44 and the microprocessor 
will repeat the step shown at block 42. If the cursor 20 is 
moved over the GUI 16, then the cursor 20 becomes a 
double-headed arrow as shown at block 46. The micropro- 20 
cessor now considers whether or not the cursor 20 has 
moved off the GUI 16 before the user has clicked the mouse 
as shown at block 48. If the mouse has moved off the GUI 

16 before the user has clicked the mouse, then the micro- 
processor returns to block 42 as shown at block 48. 25 
Otherwise, the processor considers if the user has clicked the 
mouse as shown at block 50. If the user has not clicked the 
mouse, then the microprocessor returns to block 48. 
Otherwise, the microprocessor considers the movement of 
the cursor 20 as shown at block 52. If the cursor 20 is moved 30 
left, then as shown at blocks 54 and 56, the expression of the 
avatar 17 of the GUI 16 becomes more negative. If the 
cursor 20 is moved right, then as shown at blocks 54 and 58, 
the expression of the avatar 17 of the GUI 16 becomes more 
positive. If the cursor 20 is moved neither to the left nor to 35 
the right, then as shown at blocks 52 and 60, the expression 

of the avatar 17 of the GUI 16 remains unchanged. Moving 
in the direction of the flow from any of blocks 56, 58 or 60, 
the microprocessor now considers if the user has uncHcked 
the mouse, as shown at block 62. If the mouse remains 40 
clicked, then the microprocessor returns to block 52 (to 
determine if the expression of the avatar 17 of the GUI 16 
should be further modified pending right or left movement 
of the cursor 20 by the user prior to unclicldng the mouse). 
Otherwise, the user has unclicked the mouse, and as shown 45 
at block 64, the character in the program reacts in view of 
the user's attitude as reflected in the expression of the avatar 

17 of GUI 16. At this point, the user must input his or her 
attitude to the most recent reaction of the character. 
Accordingly, the processor returns to block 42. 50 

As suggested at block 64, the current character in the 
program may react differently in view of a user's positive 
attitude as opposed to a user's negative attitude. An example 
of a possible implementation of an embodiment of the 
present invention is shown in FIG, 4, which is a decision tree 55 
illustrating possible decisions at various times during 
progress of a computer program in accordance with an 
embodiment of the present invention. The decision tree of 
FIG. 4 relates to a GUI 16 having three possible states as 
shown in FIG. 2a. of course, if the GUI 16 were pro- 60 
grammed for more than three possible states, then each node 
(where a decision is being made) of the decision tree would 
have a corresponding number of options. For example, if the 
GUI 16 were programmed to have 11 different states, then 
each node of the decision tree would have 11 options instead 65 
of the three options at each node shown in the decision tree 
of FIG. 4. 



Referring to the decision tree of FIG. 4, block 70 of the 
decision tree corresponds to block 40 of the flow diagram of 
FIG. 3. At this point, the microprocessor presents the initial 
situation or scenario on the display 10. Then, in this 
example, the user can indicate one of three attitudes to the 
initial situation, namely negative, neutral or positive. If the 
user has a positive attitude to the initial situation and adjusts 
the GUI 16 to reflect his or her positive attitude, then the 
microprocessor will cause the situation or character 14 to 
react accordingly, as shown at block 72. If, in response to the 
character's reaction, the user now has a negative altitude and 
adjusts the GUI 16 to reflect his or her negative attitude, then 
the microprocessor will cause the situation or character 14 to 
react accordingly, as shown at block 74. If, in response to the 
character's reaction, the user now has a neutral attitude and 
adjusts the GUI 16 to reflect his or her neutral attitude, then 
the microprocessor wiU cause the situation or character 14 to 
react accordingly, as shown at block 76. 

It is possible that the microprocessor can be programmed 
to react uniquely for each different block depicted in the 
decision tree of FIG. 4. In that case, at any particular step or 
block in the decision tree of FIG. 4, if the user has a positive 
attitude (for example) instead of a negative attitude (for 
example), then aU the remaining situations in the program 
will be different (from what they would have been if the user 
had a negative attitude at that point in the program). On the 
other hand, the microprocessor can be programmed so that 
it is possible to arrive at the same situation from a different 
sequence of prior attitudes. For example, the microprocessor 
could be programmed so that the same situation results from 
blocks 76 and 78 even though they each represent a different 
sequence of attitudes to previous situations. 

A partial program listing is attached as an Appendix. The 
program listing shows one possible implementation of an 
embodiment of the present invention using the programming 
language "Lingo". 

Numerous modifications and variations of the present 
invention are possible in light of the above teachings. It is 
therefore to be understood that within the scope of the 
appended claims, the invention may be practised otherwise 
than as specifically described herein. For example, the 
microprocessor could be programmed to considers other 
emotions of the user alone or in addition to the iiser's 
attitude. In the embodiment described above, left and right 
movement of the cursor 20 over the avatar 17 reflects a 
positive and a negative change in the user's attitude, respec- 
tively. Other options could be programmed. For example, 
movement of the cursor 20 towards the top of the computer 
display 10 could reflect the user becoming happier while 
movement of the cursor 20 towards the bottom of the 
computer display 10 could reflect the user becoming increas- 
ingly sad. 

Another possible modification to the embodiment 
described above is to allow the user to select one of a number 
of different avatars. For example, possible avatars could 
include an attractive woman, an old man or a muscular 
soldier. Another possible avatar may be scanned images of 
the user him or herself, which could be incorporated as part 
of the computer program from scanned photographs of 
different expressions of the user. The characters in the 
computer program may be programmed to behave differ- 
ently in a given situation to a particular avatar. For example, 
at a given point in the computer program, a character may 
react differently to an attractive woman with a negative 
attitude than to an old man with a negative attitude. 

As another possible modification to the embodiments 
described above, between blocks 62 and 64 of FIG. 3, an 
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additional element of the program could be incorporated 
involving verbal responses by the user. In this case, the 
program would incorporate voice response and recognition 
software programmed to recognize particular key words. For 
example, if a character said something causing the user to 
have a positive attitude, the user would adjust the GUI 16 
accordingly and the user might say "yeah, right" (meaning, 
perhaps "yes, I agree"). If the microprocessor were pro- 
grammed to understand the key words "yeah, right" in this 
situation, the character would then react accordingly. This 
situation is to be contrasted to a situation where the user 
having a negative attitude says "yeah, right" (which, in the 
context of a negative attitude would likely be sarcastic and 
suggest "I don't believe you"). Given the user's attitude, the 
program would construe the meaning of the expression 
"yeah, right" differently, and the next situation would pro- 
ceed accordingly. If the program is modified to include this 
speech recognition element, the decision tree in FIG. 4 
would, of course, have to be modified accordingly to incor- 
porate different additional outputs from each node of the tree 
depending upon the user's attitude to any particular situation 
in addition to the user's verbal reaction. 
What I claim as my invention is: 

1. A computer program residing on a computer- readable 
medium for use in a computer apparatus having a visual 
display device, an audio device and an input means, wherein 
the computer program, when implemented on the computer 
apparatus, 

displays on the display device a graphical user interface 
having a changeable appearance, 

enables the appearance of the graphical user interface to 
be set by a user in response to information conveyed by 
the computer program on at least one of the display 
device and the audio device, by using the input means, 
to correspond with an emotion of the user, and 

in response to the emotion of the user as represented on 
the graphical user interface, determines the content of 
and conveys further information on at least one of the 
display device and the audio device, the content of the 
further information being completely controlled by the 
computer program in response to the emotion of the 
user as represented on the graphical user interface and 
in accordance with a decision tree contained within and 
implemented by the computer program. 

2. The computer program of claim 1 wherein the program 
is configured to interact with the user such that the user may 
incrementally change the appearance of the graphical user 
interface prior to setting the appearance. 

3. The computer program of claim 2 wherein the graphical 
user interface comprises an avatar. 

4. The computer program of claim 3 wherein the emotion 
of the user as represented on the avatar is the attitude of the 
user. 

5. The computer program of claim 4 wherein the avatar is 
a face. 

6. The computer program of claim 5 wherein the input 
means comprises a pointing means. 

7. The computer program of claim 6 wherein the pointing 
means comprises a computer mouse and a cursor displayed 
on the display device. 

8. An interactive, electronic apparatus for a user to 
communicate the emotion of the user comprising: 

a display screen; 
an audio device; 

a graphical user interface visible on the display screen and 

having a changeable appearance; 
an input device for the user to set the appearance of the 

graphical user interface to correspond with an emotion 

of the user; and 
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a computer program implemented on the interactive, 
electronic apparatus, for conveying information on at 
least one of the display screen and the audio device and 
wherein in response to the emotion of the user as 

5 represented in the appearance of the graphical user 
interface, the computer program, in response to the 
emotion of the user as represented on the graphical user 
interface, determines the content of and conveys further 
information on at least one of the display screen and the 

10 audio device, the content of the further information 
being completely controlled by the computer program 
in response to the emotion of the user as represented on 
the graphical user interface and in accordance with a 
decision tree contained within and implemented by the 

15 computer program, 

9. The interactive, electronic apparatus of claim 8 wherein 
the computer program is configured to interact with the user 
such that the user may incrementally change the appearance 
of the graphical interface prior to setting the appearance of 

20 the graphical user interface. 

10. The interactive, electronic apparatus of claim 9 where 
in the graphical user interface comprises an avatar. 

11. The interactive, electronic apparatus of claim 10 
wherein the emotion of the user as represented in the 
appearance of the avatar is the attitude of the user. 

12. The interactive, electronic apparatus of claim 11 
wherein the avatar is a face. 

13. The interactive, electronic apparatus of claim 12 
wherein the input means comprises a pointing means. 

14. The interactive, electronic apparatus of claim 13 
wherein the pointing means comprises a computer mouse 
and a cursor displayed on the display screen. 

15. A method for a user to interact with a computer 
program run on a computer wherein the computer comprises 
a display means, an audio device and an input means and the 

35 computer program displays a graphical user interface having 
a changeable appearance on the display means, wherein the 
method comprises the steps of 

the computer program conveying information on at least 
one of the display means and the audio device; 

the user, using the input means, setting the appearance of 
the graphical user interface to correspond to an emotion 
of the user; and 

the computer program, in response to the emotion of the 
user as represented on the graphical user interface, 
determining the content of and conveying further infor- 
mation on at least one of the display means and the 
audio device in response to the emotion of the user as 
represented on the graphical user interface, the content 
of the further information being completely controlled 
by the computer program in response to the emotion of 
the irscr as represented on the graphical user interface 
interface and in accordance with a decision tree con- 
tained within and implemented by the computer pro- 
gram. 

16. The method of claim 15 wherein the user may use the 
input means to incrementally change the appearance of the 
graphical user interface prior to setting the appearance of the 
graphical user interface. 

17. The method of claim 16 wherein the graphical user 
interface comprises an avatar. 

18. The method of claim 17 wherein the emotion of the 
user as represented on the avatar is the attitude of the user. 

19. The method of claim 18 wherein the avatar is a face. 

20. The method of claim 19 wherein the input means 
65 comprises a pointing means. 
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